Lou Gosselin: > Thanks for responding. > I agree that normally mount syscalls don't bother telling us anything > about what's causing them to block. > Let me counter that by saying this process<->parition lock ambiguity is > unique to aufs.
Agreed. So aufs prints additional info at remounting. > Just tried against ext3, vfat, cifs, in all cases "lsof" was able to > tell me exactly which process was locking the partition or share (ie > /mnt/tmp). > lsof still works when a process is forked (see below). > lsof still works when a file is renamed "/mnt/test/b.out" > lsof still works when a file is deleted "/mnt/test/b.out (deleted)" Of course lsof can show the processes. What I want to say is to show pid is out of FS's business, because you wrote "If it output the process id(s) which caused it to fail it would be perfect" > As far as I am aware, normal filesystems have no exceptions; one can > always determine the exact processes locking a specific device (/dev/loop0) As I wrote before, there are several complicated cases to make FS busy even other than aufs. Try inotify on ext2 or something. It surely makes your FS busy and unmount-able, but lsof cannot show about it. In such case, if you know well all of your processes, then you will be able to find that the inotify is the cause. And such knowledge will be effective for aufs too, I think. In other words, if you know your processes, then the output from aufs remount will be enough for you, won't it? If you mean that to get system log is hard, then I'd suggest you to customize /etc/syslog.conf or something. J. R. Okajima ------------------------------------------------------------------------------ This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev
