On 08/20/2010 12:30 AM, sf...@users.sourceforge.net wrote: > 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. > Yes, but it lacks sufficient information to identify the exact process(es) blocking the operation. > 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" > I'm really not partial to a specific mechanism, that was a continuation from your previous suggestion.
>> 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. > I have tried this already from a prior email. Your right lsof doesn't show it, but on the other hand inotify does not appear to lock the file system in the first place. Or at least I haven't been able to produce such a scenario. Just now I tested ext2+inotify and was able to unmount it without issue. > 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. > I'm not sure where our communication is breaking down. Surely you must be getting tired of me by now, but it's difficult for me to get closure without a strait forward answer to these questions: 1) Is there a foolproof mechanism (outside of debug) to determine the exact processes locking a specific device/branch under aufs? 2) If not, should there be such a mechanism? 3) If not, do you agree this condition is unique to aufs, or can you produce a scenario where a normal linux fs or device can be locked by an unknown process? Thanks, Lou Gosselin ------------------------------------------------------------------------------ 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
