How AUFS should work when we delete a file and remount it into the union?

[fulalas]

First of all: thanks a lot for the hard work. Many exciting projects only exist because of you :)

I have a very technical question that I hope you can clarify, if you don't mind. I work on Porteus distro, which uses AUFS to mount mksquashfs modules into the union on the fly. I noticed that if I delete a file from the union (e.g /usr/bin/xfce4-taskmanager) it appears in /mnt/live/memory/changes/usr/bin as .wh.xfce4-taskmanager with zero byte. So far so good!

However, if after that I try to mount a mksquashfs module with the same file/path, it doesn't appear in the union anymore. Somehow the whiteout file has a higher priority in the stack. If I delete the whiteout file, then the real file (/usr/bin/xfce4-taskmanager) will automatically appear in the union. Also, if I manually copy (instead of mounting) the real file to the union, it appears normally and can be executed without any problem.

1- Is this the expected behavior?
2- Is there a way to set the whiteout files to have the lowest priority in the stack so that mounting mksquashfs modules into the union will make them appear for the user?

Thanks in advance!

[sfjro]

Hello, fulalas:

However, if after that I try to mount a mksquashfs module with the same file/path, it doesn't appear in the union anymore. Somehow the whiteout file has a higher priority in the stack. If I delete the whiteout file, then the real file (`/usr/bin/xfce4-taskmanager`) will automatically appear in the union. Also, if I manually copy (instead of mounting) the real file to the union, it appears normally and can be executed without any problem.

I am afraid that I cannot get fully understood what you wrote. But I try the explanation. Aufs is a stackable filesystem which means put fsA on fsB vertically, and you see the files from top of the stack. It means there is a priority between fsA and fsB. The stack top has the highest priority. If your /usr/bin/.wh.fileA exists on the stack top fsA, then all /usr/bin/fileA on the all other lower filesystems like fsB will be ignored. Even if you mount fsB again, the order in the stack doesn't change. As long as the top fsA contains .wh.fileA, all fileAs on the lower filesystems are still ignored. You can see the order in the stack via /sys/fs/aufs/si_XXX/br0, br1, ... And if you want to change the order, try aufs re-mount options, add, ins, del, append, prepend. Refer to the aufs manual for details.

1- Is this the expected behavior?

Probably Yes.

2- Is there a way to set the whiteout files to have the lowest priority in the stack so that mounting mksquashfs modules into the union will make them appear for the user?

How about this? # mount -o remount,prepend=/empty/writable/dir/like/fsC,del=/your/current/top/branch \ /your/aufs/mountpoint But I am not sure that I could fully understand what you did and what you want to do.

First of all: thanks a lot for the hard work. Many exciting projects only exist because of you :)

Glad to hear that! It surely drives me keeping developing aufs. J. R. Okajima

[fulalas]

@sfjro, thanks for your reply! I made video so I can explain better what I mean. Just follow the cursor and you'll understand everything (I hope :P)

aufs.mp4

[sfjro]

fulalas:

@sfjro, thanks for your reply! I made video so I can explain better what I mean. Just follow the cursor and you'll understand everything (I hope :P)

Unfortunately due to the resolution of my display (probably), the texts in the video are too grainy and hard to read. But I think I could understand what you are doing. The answer is same to my previous mail. You are removing and re-adding the branch under the top of the stack. The white-out exists on the top branch which hides the lower same-named entires. J. R. Okajima

[fulalas]

@sfjro, the downscale video in Github is pretty bad. You have to watch in full screen -- you'll be able to even see the commands I'm using to add the module to the union, which is mount -no remount,add:1:"$MODULE"=rr aufs /

You are removing and re-adding the branch under the top of the
stack. The white-out exists on the top branch which hides the lower
same-named entires.

So, if I understand correctly, what determines a branch is actually the path/files of its content in the union. Interesting! But it's still unclear how to set the whiteout to have the lowest priority in the stack in such a way that when trying to add the same branch again the whiteout will be ignored and the file will appear in the union.

[sfjro]

@sfjro, the downscale video in Github is pretty bad. You have to watch in full screen -- you'll be able to even see the commands I'm using to add the module to the union, which is `mount -no remount,add:1:"$MODULE"=rr aufs /`

As aufs manual describes, ---------------------------------------- .B [ add | ins ]:index:BRANCH Adds a new branch. The index begins with 0. ---------------------------------------- Your whiteout exists on the branch whose index is 0. It hides the same path on all lower branches, ie. index>=1.

So, if I understand correctly, what determines a branch is actually the path/files of its content in the union. Interesting! But it's still unclear how to set the whiteout to have the lowest priority in the stack in such a way that when trying to add the same branch again the whiteout will be ignored and the file will appear in the union.

One solution is yours which is to remove the whiteout manually. In this case, I'd suggest you to set the mount option 'udba=nofify'. Another solution is in my first reply which is ---------------------------------------- # mount -o remount,prepend=/empty/writable/dir/like/fsC,del=/your/current/top/branch \ /your/aufs/mountpoint ---------------------------------------- It changes the order of branches from 0: /your/current/top/branch 1: /your/squashfs/mountpoint to 0: /empty/writable/dir/like/fsC 1: /your/squashfs/mountpoint Since the whiteout is in /your/current/top/branch, and new /empty/writable/dir/like/fsC doesn't contain any whiteout, all the entries on /your/squashfs/mountpoint will re-appear. You might be wondering that reversing the order of branches such as from 0: /your/current/top/branch 1: /your/squashfs/mountpoint to 0: /your/squashfs/mountpoint 1: /your/current/top/branch You may be able to do that by remounting aufs with add/del options, but you may NOT able to remove any entries in squashfs because you have no upper writable branch. J. R. Okajima

[fulalas]

Hello! Sorry for the long delay -- I've been busy.

I'm trying to do what you said, but there's something missing. I'm assuming the code you suggested is the one to remove a squashfs from the union, not to load it. So this is my original script to remove a squashfs module:

mount -t aufs -o remount,del:"$MODULE" aufs /
umount -nd "$MODULE"
rmdir "$MODULE"

Reading your instructions, I tried to adapt to this:

mkdir /tmp/$BASEFILENAME
mount -t aufs -o remount,prepend=/tmp/$BASEFILENAME,del="$MODULE" aufs /
umount -nd "$MODULE"
rmdir "$MODULE"

When I run it (after the module is inserted in the union) it says mount: /: mount point not mounted or bad option. What am I missing?

Thanks once again :)

[sfjro]

fulalas:

I'm trying to do what you said, but there's something missing. I'm assuming the code you suggested is the one to remove a squashfs from the union, not to load it. So this is my **original** script to remove a squashfs module:

No, you are misunderstanding. Leave your squashfs, and renew your upper branch. But I am afraid there is another problem because of this msg.

When I run it (after the module is inserted in the union) it says `mount: /: mount point not mounted or bad option`. What am I missing?

Next time when you write, these info please. (from aufs README) ---------------------------------------- When you have any problems or strange behaviour in aufs, please let me know with: - /proc/mounts (instead of the output of mount(8)) - /sys/module/aufs/* - /sys/fs/aufs/* (if you have them) - /debug/aufs/* (if you have them) - linux kernel version if your kernel is not plain, for example modified by distributor, the url where i can download its source is necessary too. - aufs version which was printed at loading the module or booting the system, instead of the date you downloaded. - configuration (define/undefine CONFIG_AUFS_xxx) - kernel configuration or /proc/config.gz (if you have it) - LSM (linux security module, if you are using) - behaviour which you think to be incorrect - actual operation, reproducible one is better - mailto: aufs-users at lists.sourceforge.net ---------------------------------------- And did you install aufs-util.git on your system? J. R. Okajima