> I was wrong again, confirmed that lsof prints the correct inum even it > is removed. > But the conlusion won't change much. > > (a scenario you have written) > - mount -o br:/a none /u > - invoke u/sh, which is a/sh actually > - prepend /b, /u = /b + /a > - invoke u/sh, which is b/sh actually > > And > - both u/sh has 10 as its inode number (for example) > - a/sh has i20, and b/sh has i30 > - lsof shows i10 only for two sh processes > > Even if lsof provides i10 and aufs provides all three inode numbers, you > still need ways to find the process which refers i20 (or i30). > I was thinking aufs would return a different inode since it was a different file, but I see that it does not, and in fact that makes sense at least when copy up is working normally.
I'm confused about the results below. a/sh and b/sh are two different executables (using the aufs prepend option) -bash-4.1# lsof | grep "tmp/u" sh 1220 root txt REG 0,14 30224 12 /tmp/u/sh sh 1227 root txt REG 0,14 30224 12 /tmp/u/sh -bash-4.1# cat /proc/1220/maps | grep "tmp" 08048000-0810b000 r-xp 00000000 00:0e 12 /tmp/u/sh 0810b000-0810c000 r--p 000c2000 00:0e 12 /tmp/u/sh 0810c000-08111000 rw-p 000c3000 00:0e 12 /tmp/u/sh -bash-4.1# cat /proc/1227/maps | grep "tmp" 08048000-0804f000 r-xp 00000000 00:0e 12 /tmp/u/sh 0804f000-08050000 r--p 00006000 00:0e 12 /tmp/u/sh 08050000-08051000 rw-p 00007000 00:0e 12 /tmp/u/sh -bash-4.1# How does linux know which file to read under the hood? There must be a key it's not displaying in the proc/x/maps? I'm speculating here: my guess is that the VMM is pointing to a struct inode which has been copied up by aufs into a new inode, but the VMM continues to refer to the old one. The new and old struct inode continue to share i_ino #. If this is the case, would it be possible to assign the old inode struct a new unique i_ino? The rational being that the # should be unique per device, and the old struct inode is never accessed using the old # anyways. (The old struct is never accessed at all outside of mmap, which continues to use it's pointer). The unique inode number would solve the current ambiguity. Then userspace, in theory, should show that the new and old branches always use different inodes in /proc/x/maps and lsof. As an aside, was the decision to leave mmap files on their old branch deliberate (maybe to keep executables working)? Or was it just how the code played out? ------------------------------------------------------------------------------ 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
