On 08/19/2010 10:30 PM, sf...@users.sourceforge.net wrote:
> 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
>
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.
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)"
As far as I am aware, normal filesystems have no exceptions; one can
always determine the exact processes locking a specific device (/dev/loop0)
The ambiguity only arises with aufs, as discussed in earlier emails.
1) There is no foolproof mechanism (outside of debug) to determine the
exact processes locking a specific device/branch under aufs.
2) In my opinion, maybe there ought to be.
You seem to disagree with me strongly, is it statement #1 or #2 that you
disagree with?
#include <unistd.h>
#include <fcntl.h>
int main() {
int f = open("test", O_RDWR, 0);
fork();
while(1) sleep(1);
}
a.out 5189 root cwd DIR 7,0 16384 1
/mnt/test
a.out 5189 root rtd DIR 8,1 4096 2 /
a.out 5189 root txt REG 7,0 7211 24
/mnt/test/a.out
a.out 5189 root mem REG 8,1 1405508 770052
/lib/tls/i686/cmov/libc-2.11.1.so
a.out 5189 root mem REG 8,1 113964 745869
/lib/ld-2.11.1.so
a.out 5189 root 0u CHR 136,3 0t0 6
/dev/pts/3
a.out 5189 root 1u CHR 136,3 0t0 6
/dev/pts/3
a.out 5189 root 2u CHR 136,3 0t0 6
/dev/pts/3
a.out 5189 root 3u REG 7,0 0 29
/mnt/test/test
a.out 5190 root cwd DIR 7,0 16384 1
/mnt/test
a.out 5190 root rtd DIR 8,1 4096 2 /
a.out 5190 root txt REG 7,0 7211 24
/mnt/test/a.out
a.out 5190 root mem REG 8,1 1405508 770052
/lib/tls/i686/cmov/libc-2.11.1.so
a.out 5190 root mem REG 8,1 113964 745869
/lib/ld-2.11.1.so
a.out 5190 root 0u CHR 136,3 0t0 6
/dev/pts/3
a.out 5190 root 1u CHR 136,3 0t0 6
/dev/pts/3
a.out 5190 root 2u CHR 136,3 0t0 6
/dev/pts/3
a.out 5190 root 3u REG 7,0 0 29
/mnt/test/test
------------------------------------------------------------------------------
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
