> What you did is, > - mount -o remount,del:/squashfs /aufs > - umount /squashfs > - some operation > - aufs crashes
yes, exactly. The 'umount /squashfs' part sometimes causes the error message "VFS: Busy inodes after unmount loop* ... etc", so I _think_ the loop just dies because of aufs and then aufs is confused :) It's just my guess. It seems to me the problem is only with a branch where some files were opened in the past. There is one important note to say: if the branch is busy, the remount,del does nothing of course. Remount shows '/ is busy' and the system can work correctly. BUT, if the branch is NOT busy (or maybe it IS busy but aufs doesn't know) then it can be deleted without any error and THEN unmounting the branch's loop-source fails in VFS. > Please tell me how to reproduce this problem. > I want to reproduce your environment on my pc. Hm it's hard :) My problem is that I usually can't reproduce it in a normal Linux environment, I'm still finding these things in Slax, which is a chrooted OS and makes things hard to debug. Nevertheless, you can download Slax from here http://www.slax.org/dl/slax6broken.iso - burn it to CD, boot it, choose the third option from boot menu (start Slax with KDE directly). - while in KDE, run konsole and execute: $ mount -n -o remount,del:/mnt/live/memory/images/008-office.lzm aufs / $ umount /mnt/live/memory/images/008-office.lzm $ dmesg Interesting thing is, that if I try to remove '009-devel.lzm' instead (using the same commands), I never get the error. For this tests I use noplink mount option to create the aufs union, but it's the same without the noplink. Another note, maybe important, maybe not - I'm using Vanila Kernel with squashfs patch and loop patch. Since the error message (VFS:...) contains a reference to the loop device, I'm mentioning the fact I'm using a patch http://ftp.linux.cz/pub/linux/slax/source/slax/kernel/2.6.21.2/src-core/patches/loop/loop.c.diff But I believe it is not the reason for our problem, as this patch should be included in 2.6.22 or 2.6.23 mainline kernel so it should be safe. >> I tried the patch you sent me, but it does nothing, or I can't see any >> output in dmesg after remount,del, I'm sorry. > > And EBUSY error returned? > Then it means, > - one or more files were opened on that branch. This is possible but i'm unable to say, I don't know. I hope the feature to see this info through /sys will be implemented soon :) > Or can you receive the kernel debug log? > Try, > # echo 8 > /proc/sys/kernel/printk > (/etc/syslog.conf) > kern.debug /var/log/debug.log > # restart your_syslog_daemon I can do this, still the same, no info either in dmesg or on konsole. Thank you very much for taking care about this! Tomas M ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/
