Lou Gosselin: > Sorry for the delay. > I did give this a shot. It's definitely closer but still doesn't > pinpoint the blocking process for all scenarios. > If it output the process id(s) which caused it to fail it would be > perfect and it wouldn't require aufs to be compiled with debug to parse > the the verbose sysreq output.
For any FS, generally it is very hard (nearly impossible) to know the pid of opening a file in the FS. You may think it has to be possible by modifying open(2). But the file object in kernel is shareable between multiple processes. For instance, a child process (created by fork(2)) may share the file descriptor in its parent process. Additionally a process can send the file descriptor to another process to share. It means modifying only open(2) is insufficient. Finally I'd say it is not the job of FS. 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
