I want to build the AUFS Linux filesystem for Linux kernel 6.6.31. Where can I get the source code and how to build it and lastly, how do I get the .ko file?

I wish to separate the default packages configuration files (/etc/), and the configuration files I edited e.g. in /Data/etc/ (normally should be /usr/local/etc/, but let assume /Data/etc/). This to enable me to easily see the modifications I made, to easily back it up, etc. Therefore, I was wondering it was possible to mount /etc/ as : - upper layer FS in RO : /Data/etc/ - lower layer FS in RW : itself (/etc/). The package manager would make its changes in /etc/ like normal. But when I add a file in /Data/etc/, e.g. /Data/etc/foo, I wish to then have a /etc/foo file in RO that will shadow any existing /etc/foo. Note: - physical links aren't possible as /Data and /etc will be in different FS. - symbolic links would be troublesome : e.g. if a symlink is deleted when updating a package, requires to automatically create a symlink for each files in /Data/etc/, etc. - mount --bind would be troublesome for the same reason. - some packages does look at /usr/local/etc/ for extra-configuration files, but unfortunately, not all. However, I failed to see how to do so with UnionFS/AuFS/OverlayFS/etc. I am also open to alternative solutions/ideas.

I have randomly been reading about union file system which enables a user to mount multiple filesystems on top of one another simultaneously. However, am finding trouble deciding on which one to use(Unionfs vs Aufs vs Overlayfs vs mhddfs) and why as I have not found concrete information on the subject anywhere. I know for instance that overlayFS has been adopted in the mainstream Linux kernel which means it might get wider adoption. Would appreciate if someone would give me some perspective. Also I can't find any conceiving use-case for Union file system over something like LVM (as recommended by users in separate question ) or RAID setup except in the fact that LVM requires formatting all the drives which might not be desirable if you already have valuable data on the drives.

I multiboot several distributions which are at separate subvolumes. They are stored in a not standardised layout. I have some subvolumes which I want mounted in a layered way. I prefere to use aufs . For example, I want /home/myname to be mounted at every dist . I also want some generic /use/share/bin to be overlay mounted with the dist-specific one. There are to many subdirs/files to maintain symlinks instead of overlay-mount. Due to cow-issues between btrfs and layered FS , I understand that I should not use layered fs together with btrfs. I figured out that I maybe could overlay-mount read-wtiteable ext4 images , which resides on btrfs-subvols. I suppose I then should disable CoW for just the wm images. In that way I could still snapshot the subvols which contains the image-files. I mainly would like to know if there is better solutions to combine btrfs and layered fs .

I'm trying to translate whiteout files from the AUFS format to the kernel-overlay FS format. This entails marking certain directories with the extended attribute trusted.overlay.opaque = y. Unfortunately, it seems that at least by default, FreeBSD only supports the user and system namespaces for extended attributes. Is there any way around this restriction? The manual for extattr implies that some file system I could mount might support other namespaces, perhaps including the trusted namespace, but I haven't been able to find a namespace that I can mount and that does indeed allow for use of the trusted namespace. Unfortunately, I'm unable to upgrade to a supported FreeBSD version. Additionally, while KOFS has a flag to read its opaque whiteout files from the user namespace instead of the trusted one, we're stuck building our KOFS on top of tempfs, which does not support user namespace extended attributes. Any thoughts?

I've been learning docker and decided to try out the unionfs aufs. But I couldn't find a way to do it. I tried mount -t aufs but it complained that aufs was unknown. $ sudo mount -t aufs -o dirs=./container-layer:./image-layer4:./image-layer3:./image-layer2:./image-layer1 none ./mnt mount: unknown filesystem type 'aufs' I've searched the Internet but still can't figure out a way to mount aufs filesystem. I'd appriciate it if someone can tell how to mount aufs filesystem or just redirect me to some links. **OS**: Ubuntu16.04 **uname -a**: Linux myzone 4.14.13-041413-generic #201801101001 SMP Wed Jan 10 10:02:53 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux By the way, no **aufs** in /proc/filesystem and aufs-tools was installed.

I came to the conclusion that aufs is limited to 127 layers based on tests. **(prepare)** mkdir write joined {1..400} for((i=1;i$i/$i.txt;done #for checks **using a single mount, the limit is 84 layers (numbereds + the write one).** The folder name doesn't change the 84 limit (so each could be bigger ex. "layer-72", therefore not a string size limitation). sudo mount -v -t aufs \ -o "sync,br=write:1:2:3:4:5:6:7:8:9:10:11:12:13:14:15:16:17:18:19:20:21:22:23:24:25:26:27:28:29:30:31:32:33:34:35:36:37:38:39:40:41:42:43:44:45:46:47:48:49:50:51:52:53:54:55:56:57:58:59:60:61:62:63:64:65:66:67:68:69:70:71:72:73:74:75:76:77:78:79:80:81:82:83:84" \ "none" "joined";echo $? The above will fail, unless you remove ":84" from the end. **Using remount, it can go up to 127 layers (numbereds + the write one)** sudo mount -v -t aufs -o "sync,br=write" "none" "joined";echo $? for((i=1;i<=400;i++));do echo "try $i"; if ! "sudo" "mount" -v "-o" "remount,append:$i" "joined";then break; # it stops with error "No space left on device", but is not related to free bytes on storage! fi; ls -l joined/$i.txt; done **research** I am trying to use mount.aufs just to see readable error messages, as mount -v is not helping. Is there documentation specifying how to translate mount parameters to mount.aufs? I am still trying to find mount.aufs source code too; that could help my understanding of what parameters it accepts. **Alternative acceptable answer** Is aufs patchable (as apparently 127 is a hard-coded limit)? Is it worth the effort/mess, or more than 127 may cause performance issues as suggested on comments? Could an alternative folders merger provide more than 127 layers? If so, which one? Here a list I found: overlayfs unionfs mhddfs mergerfs docker. What commands I should use based on the test case I provided above? aufs is quite clear and simple to use and understand, and that was the main reason I chose it. PS.: I am using this now: https://unix.stackexchange.com/questions/704168/how-to-make-mergerfs-behave-like-i-did-aufs-behave-only-write-everything-new-or/730165#730165

I need this behavior because I need to know what the application using the merged folder will do, so I can backup it properly and consistently with small backups. I need to force it behave like I did with aufs because I am migrating my script that used aufs, but not only because of that. That behavior is mandatory for the layers I created and were working very well. All my work branches (directories) are subfolders of the same folder (that is where the merged folder is placed), therefore share the same available space. These options work +- well: defaults,allow_other,use_ino,category.action=ff,category.create=ff,category.search=ff but if I modify one file at the merged folder, it will remove the file from the original folder :O and create/update the modified file on the first folder found :(, it should not touch the original file :(. If there is several overrides, it deletes them all leaving only the last modification on the first folder :O, it is good I know, but not for my script/useCase. If I make all branches' folders and subfolders readonly, this will prevent the deletion of the files, so all updates will go to the first folder. But then, I will still need to make each branch(subfolders and files too) RW, change things there and do not forget to set it RO again or things will mess up. So I still can't make it behave like AUFS did. It is close but not equal. PS.: ubuntu22.04 has aufs no more, so no going back

similar questions have been asked multiple times ... - https://unix.stackexchange.com/questions/126380/how-to-use-an-ssd-for-caching-so-my-hard-disks-can-spin-down - https://unix.stackexchange.com/questions/122386/caching-write-changes-on-ssd-to-avoid-hdd-spin-up-zfs-but-probably-not-l2arc - https://superuser.com/questions/664400/ssd-cache-to-minimize-hdd-spin-up-time - https://unix.stackexchange.com/questions/382326/unionfs-vs-aufs-vs-overlayfs-vs-mhddfs-which-one-do-i-use?rq=1 - https://unix.stackexchange.com/questions/393930/merge-changes-to-upper-filesystem-to-lower-filesystem-in-linux-overlay-overlayf ... but none of them has a answer. As most of those questions are old (2012-2015), I'm trying again. I have a 6 GB ZFS pool that is mostly idle. Still it's too busy to get the disks to spin down, as there are always some small writes on the server. By powering the disks down for long periods, I want to keep wasted energy at a minimum. I want to emphasize that performance is *not* my concern (the pool is fast enough), but rather energy consumption. My idea is to add a 1 TB SSD to the system as "persistent cache" (not sure if that's the right word). More specifically, the system should do the following: - Reads are initially answered from the pool, but the file (or blocks) in question should be stored on the SSD. Subsequent reads should be answered from the copy on the SSD. - Writes are stored on the SSD. Rarely (like every three days), new files should be written to the pool. Are there solutions to this problem? From my research, I found that - AUFS might be able to solve my problem but it's not included in the kernel. I don't know if there is a userspace driver and how good it is. - Instead, OverlayFS was pushed by the Linux community. To me, it seems that my use case is explicitly unsupported (as upper folders cannot be merged into lower folders, for whatever reason). If I understand correctly, OverlayFS actually sees that as a feature instead of a shortcoming - that would imply uselessness for my use case. - bcache: bcache in writeback mode with high writeback time does appear promising. However, the documentation states that "it will let sequentials reads/writes on HDD/Raid devices by default". Is there a way to turn this behavior off? Also I don't want writing back to happen too early and that appears to be problematic. - MergerFS: I don't know if it can do what I need. Are there any tools/solutions/suggestions that I didn't see yet?

AFAIK with [aufs](https://en.wikipedia.org/wiki/Aufs) when a file is touched (ie. only it's metadata changed, not it's contents), then the copy-on-write mechanism of the file system will copy the whole file into the r/w layer, essentially duplicating the file. Say, I only want to change the **metadata** (modification time, permissions, owner, etc.) of a *lot* of files, is there some union-type file system (OverlayFS perhaps?) that only keeps track of the metadata changes, unless the file *content* is altered - resulting in much less duplication? Or maybe some other trick can lead to the desired result?

I am having significant problems using Docker on my BTRFS filesystem, and I suspect that is due to a lack of stability with the BTRFS driver. I would rather figure out how to switch the fs driver than ask multiple questions about the problems I have been having. Originally it would fill my hard drive with about 4 builds of any Dockerfile and deleting images and containers would not help (and this is with ~80GB of space left); I also had to delete BTRFS subvolumes from /var/lib/docker/btrfs/subvolumes. Now I have a still-more-annoying problem where no images can be pulled because a file or directory exists (in a location which is completely removed first). So because these problems have been so cryptic and un-Googleable, I'd like to just force the driver to be AUFS. How do I go about doing this? I am using 64-bit Arch Linux. Any guidance or pointers in the right direction would be greatly appreciated.

*Disclaimer: I'm a newb and I need step by step guide. Thanks!* I want to first install grub without OS, since it will boot from ISO file off the local network storage. I'm booted into a liveCD (I can't install it since I need a volatile system) I'm already stuck at first stage. I tried grub-install /dev/sda and I get error saying grub-install: error: cannot open directory '/boot/grub/i386-pc': No such file or directory. So I created and copied all files it grub-install needed and now it says grub-install: error: failed to get canonical path of 'aufs'. I searched web and figure most answers requires me to use chroot while I have a installed system (can be broken though) I don't have Ubuntu installed to any drive and my goal is to **install grub from liveCD to empty drive**. I want to start with an empty boot loader. How do I do this? Thanks again in advance.

I am looking for a stackable file system (Like UnionFS, aufs, and OverlayFS) that works similar to bcache or lvmcache but on file level - not on block level: - Reads will be done from top-layer. If the file is not there, read the file from bottom-layer and store it in top-layer. - Writes will be done to top-layer. After write is done, it will also be written to bottom-layer (like write-back/write-behind caching) - When the top-layer reaches a certain size, files will be erased from the top-layer (like an LRU cache). Files will only be removed if they have been written to bottom-layer. For my use bottom-layer will be 10-1000 times bigger than top-layer - in other words: bottom-layer will not fit in top-layer (again similar to bcache). Does such stackable file system exist? Can it be done with aufs or similar? **Background** I *love* file systems, and use all sorts of Fuse-based file systems. But file systems like sshfs can be rather slow, and it would be really handy to have a way of speeding that up if you know that the bottom-layer will only be changed through this system. Using an sshfs mounted dir as the bottom-layer is just one example, so I am not looking for a specialized approach, that deals with sshfs. I am looking for a general approach where the top-layer and the bottom-layer are just treated as dirs.

I want to union some folder, current I use mergerfs, I try to test aufs. When I mount aufs, it jump a error.

$sudo mount -t aufs -o br=./a:./b none ./c
mount: /home/t/c: wrong fs type, bad option, bad superblock on none, missing codepage or helper program, or other error.

I have install aufs-dev aufs-dkms aufs-tools, and I can found it in filesystems and lsmod.

$grep aufs /proc/filesystems
nodev   aufs

$ lsmod | grep aufs
aufs                  274432  0

$uname -a
Linux lin 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11) x86_64 GNU/Linux

$ apt list | grep aufs
aufs-dev/stable,stable,now 4.19+20190211-1 all [installed]
aufs-dkms/stable,stable,now 4.19+20190211-1 all [installed]
aufs-tools/stable,now 1:4.14+20190211-1 amd64 [installed]

Is there something config that I am missing?

I am considering using a union filesystem, such as aufs, UnionFS or OverlayFS. I have a 138GB of Android source, to which I want to make minor changes and keep them under version control. My plan is to mount a unionfs on top of the (now read-only) Android source, and make edits on the unionfs. In order to commit changes to version control, I will also need to have a view of the unionfs *without* the underlying, read-only, Android source. Do any of the union filesystems allow a volume to be mounted simultaneously with and without an underlying filesystem? (If not the strategy could still work, but would require some unmounting and mounting around every commit.)

A follow-up from [this question](https://unix.stackexchange.com/questions/510931/overlay-storage-driver-internals) . After reading Docker Storage drivers from [official doc](https://docs.docker.com/storage/storagedriver/overlayfs-driver/#overlayfs-and-docker-performance) I understood that overlay was faster than aufs because it had only one hard linked image layer. But for overlay2, document says overlay2 supports multiple layers as aufs, but mitigates any performance hit with caching. I couldn't find any reference that was showing how overlay2 is better at caching than aufs, can someone give me advices?

My question is the opposite of most on AUFS. I don't need to know how to mount two or more directories in a union. Instead I need to understand what I am seeing on an existing system. / aufs aufs rw,noatime,si=1725e3c381716971,noxino I have discovered the findmnt -T path will tell me which mount a directory belongs to but I don't see a way to tell which physical drives are being merged by the aufs I pasted above.

I've recently read this interesting suggestion under "Performance best practices" subtitle here: https://docs.docker.com/storage/storagedriver/aufs-driver/ > **Use volumes for write-heavy workloads**: Volumes provide the best and most predictable performance for write-heavy workloads. This is > because they bypass the storage driver and do not incur any of the > potential overheads introduced by thin provisioning and copy-on-write. > Volumes have other benefits, such as allowing you to share data among > containers and persisting even when no running container is using > them. ..and Ok, when provisioning each one of our containers, we always think about major needs, based on the reason of existence of this container, and determine which directories should be a volume because there's going to happen tons of read/write. **My question is**: how to inspect a container file-system to determine if some directory inside it should be a volume and '*bypass the storage driver*' but it still not bypassing? Let me explain a little more: Lets say I check out /var/log inside a container to see what is happening there.. and I realize there is a process log-files with lots of writing per minute so I decide to transform it as a volume. But, what if there is another dir like /var/www or /var/spool, or something else? Is there any way to check the most requested areas of the file-system inside a container, in terms of IO?

I'm trying to have this done on a debian 9 based embedded system. The fs that come for root is mounted as such in /etc/fstab: # /etc/fstab: static file system information. # /dev/mmcblk1p1 / ext4 noatime,errors=remount-ro 0 1 debugfs /sys/kernel/debug debugfs defaults 0 0 My current file system looks like this: Filesystem Size Used Avail Use% Mounted on udev 215M 0 215M 0% /dev tmpfs 49M 6.0M 43M 13% /run /dev/mmcblk1p1 3.5G 1.9G 1.4G 59% / tmpfs 242M 0 242M 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 242M 0 242M 0% /sys/fs/cgroup tmpfs 49M 0 49M 0% /run/user/1000 Now what I'm required to do is use unionfs (or aufs) + ext4 to create a more resilient mounting system because /ext4 might fail due to power outage and file corruption might occur. The idea here is to have a readonly file layer at the bottom with a writable one on top for /home/debian as well as any other that might require system writing to them (like var/log dir). What I was told is that ext4 working with an embedded system that might loss power unexpectedly on regular basis, would cause series disk issues/corruption especially since we are going to be writing to disk alot while our Application is running.[(Link)](https://serverfault.com/questions/391302/can-ext4-fs-be-completely-unrecoverable-broken-due-to-power-loss-while-disk-is-w) . IS this completely true even with the presence of Journaling in ext4? After hours and hours of researching I found that it is suggested to go through the /usr/share/initramfs-tools by creating hooks/scripts and such. After creating new script and booting my system I was able to get something similar to what I had wanted: Filesystem Size Used Avail Use% Mounted on udev 215M 0 215M 0% /dev tmpfs 49M 6.0M 43M 13% /run /dev/mmcblk1p1 3.5G 1.9G 1.4G 59% /ro root.rw 242M 8.5M 234M 4% /rw root.union 242M 8.5M 234M 4% / tmpfs 242M 0 242M 0% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 242M 0 242M 0% /sys/fs/cgroup tmpfs 49M 0 49M 0% /run/user/1000 && using mount I get the following details for newly added ro && rw file systems: /dev/mmcblk1p1 on /ro type ext4 (ro,relatime,data=ordered) root.rw on /rw type tmpfs (rw,relatime) root.union on / type aufs (rw,relatime,si=587d3414) Now this has worked in terms of making my initial / read only system that is in /ro dir && I have installed on top a writable layer in /rw. The issue here is that if I create new files/dir they are all gone after booting the device. Looking deep into this I suspect the fact that I was using tmpfs might have caused that since it is used normally for RAM, but I have tough using aufs on top (root.union) would solce tis issue but it didnt. How can I solve this issue by making the /rw layer retain any new information/files created even after boot? Keep in mind my system is read only now so everytime I try to go into my script and mount /rw as aufs it is reverted back after booting the device. Note: Does my current set up mean that logs from my current App are not logged to my /var/log/... and are lost after booting device? some Apps would usually log to /var/log/syslog which is in /rw directory but I can't seem to confirm if they are retaining new logs after boot up or just reverting to what they had at start up in them?

I am trying to set up a read-only filesystem at /root directory on my embedded device. I have following in code in my boot init command file /sbin/init-overlay: rootmnt=/root ro_mount_point="${rootmnt%/}.ro" rw_mount_point="${rootmnt%/}.rw" # For local system rearranged from init /bin/mkdir -p "${ro_mount_point}" "${rw_mount_point}" # Move the already-mounted root filesystem to the ro mount point: /bin/mount --move ${rootmnt} ${ro_mount_point} # Mount the read/write filesystem: /bin/mount -t tmpfs root.rw "${rw_mount_point}" # Mount the union: /bin/mount -t aufs -o dirs=${rw_mount_point}=rw:${ro_mount_point}=ro aufs ${rootmnt} # Correct the permissions of /: /bin/chmod 755 "${rootmnt}" # Make sure the individual ro and rw mounts are accessible from within the root # once the union is assumed as /. This makes it possible to access the # component filesystems individually. /bin/mkdir "${rootmnt}/ro" "${rootmnt}/rw" /bin/mount --bind "${ro_mount_point}" "${rootmnt}/ro" /bin/mount --bind "${rw_mount_point}" "${rootmnt}/rw" This is my boot command: console=ttyS0,115200 earlyprintk root=/dev/mmcblk0p2 rootfstype=ext4 rootwait fsck.repair=${fsck.repair} panic=10 ${extra} fbcon=${fbcon} rw init=/sbin/init-overlay But while booting, I am getting the following error: mount: mounting /root on /root.ro failed: Invalid argument Can anyone point-out what's wrong here?