equetzal
AUFS unremovable usrchanges/ branch
Ok, so this problem its being hard to trace and to solve, but let's get some context.
huronOS, have its AUFS setup like:
br0 /run/initramfs/memory/usrchanges/ /dev/sdb3
br1 /run/initramfs/memory/syschanges/
br2 /run/initramfs/memory/base/01-core.hsl/ /dev/loop4
br3 /run/initramfs/memory/base/02-firmware.hsl/ /dev/loop3
br4 /run/initramfs/memory/base/03-budgie.hsl/ /dev/loop2
br5 /run/initramfs/memory/base/04-shared-libs.hsl/ /dev/loop1
When huronOS automatically change its "execution mode", it needs to change the usrchanges/ device from /dev/sdb3 to /dev/sdb2, as this devices storage the persistent changes.
mount /dev/sdb2 $MEMORY/event/
mount /dev/sdb3 $MEMORY/contest/
mount --bind $MEMORY/event $MEMORY/usrchanges/
So, to change the persistence device, it remove the usrchanges/ branch, then remove the bind, remount the bind but with the second storage device and then insert the branch into AUFS. The problem is that, sometimes (rare), AUFS won't be able to delete the usrchanges/ branch because the device is busy. When checking the kernel logs, we can see the AUFS inode number which is making the branch busy, but when searching for the files with this inode, we can firsly notice that there's more than 1 file with the same inode, and also, none of this inodes are within the usrchanges/ branch. Also, something notable is that neither aubusy or auibusy aufs-tools are able to find the PID of the process with the inode. And when this happens, the duplicated inode is located within /sys/ directory.
So this is kind of a lost inode which AUFS thinks is on our usrchanges/ branch, or the inode is on the branch but somehow we cannot find it. The problem is that, the udba=reval mount option is already present, so in theory the problem should be solved as stated on the AUFS MAN.
So I might be needing to contact to Junjiro, but I would like to do it with a always reproducible test case for get a better idea of what is happening.
For now, the solution might be using kexec tool for automate a "system reboot" when hitting this specific case, but more testing over that "patch" needs to be done.
