> I don't understand why mmap case is special? > Do you mean you can find the right file in other cases, but you cannot > only in the mmap case? > > Yes.
An mmap running on a lower branch will lock the lower branch, even when the file is touched and copied up or is unlinked. Conversely, an mmap running on an upper branch will continue to lock the upper branch, even when the same file exists in the lower branch, or is unlinked. Both conditions, with regards to lsof and ls a/ ls b/, return the same output. Even though the answer is different. Here is lsof output (in this case only the third has a lock on "a") sh 1370 root txt REG 0,18 818232 11 /tmp/union/sh sh 1375 root txt REG 0,18 818232 11 /tmp/union/sh sh 1380 root txt REG 0,18 818232 11 /tmp/union/sh Even more confusing, if I rename sh to sh2: sh 1370 root txt REG 0,18 818232 11 /tmp/union/sh2 sh 1375 root txt REG 0,18 818232 11 /tmp/union/sh2 sh 1380 root txt REG 0,18 818232 11 /tmp/union/sh2 Now the first two procs are locking branch b, which doesn't even contain the file lsof claims is locked. Hopefully we're on the same page now, do you concur that there is no way to identify the source of an mmap file lock without looking into aufs state? Lou ------------------------------------------------------------------------------ The Palm PDK Hot Apps Program offers developers who use the Plug-In Development Kit to bring their C/C++ apps to Palm for a share of $1 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm
