sf...@users.sourceforge.net: > Lou Gosselin: > > Yes, either directly or indirectly, it is what I'm after. Although in > > the past you indicated this would be difficult since filesystems in the > > kernel are oblivious to processes? > > Exactly. > Every filesystem doesn't know about the process which is using a file in > it. But lsof gives us the process-file relationship. If we (or a new > utility) gives this relation to a kernel module (which may be separated > from aufs itself), when it will be able to identify the busy inode on > the branch.
Hi Lou, I forgot that I had implemented the separate inode number which you suggested in the message, http://www.mail-archive.com/aufs-users@lists.sourceforge.net/msg02885.html I implemented this scheme as a part of the new refresh approach in last Dec. So the inum of these two u/sh are different from each other. > > - 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 > > - 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 "both u/sh has 10" is wrong now. And I tesed a new script and a new ioctl in aufs. It seems working. I'd ask you to take a look and confirm it will be fine. If you tell me your kernel version, I will send you the patch. Would you test it? (output from my test script) ---------------------------------------------------------------------- none /dev/shm/u aufs rw,relatime,si=11a10e6a93d68c6d 0 0 /dev/shm/rw=rw /dev/shm/ro=ro + cd /dev/shm/u + mkdir /tmp/4362.dir + cp /bin/sleep /tmp/4362.dir + test -x ../ro/sleep + test ! -x ../rw/sleep + stat -c %i ./sleep + ino1=11 + sleep 1 + ./sleep 100 & + pid1=4553 + echo 4553 11 4553 11 + sudo mount -o remount,prepend:/tmp/4362.dir /dev/shm/u + stat -c %i ./sleep + ino2=13 + sleep 1 + ./sleep 100 & + pid2=4560 + sudo mount -o remount,del:../ro /dev/shm/u mount: /dev/shm/u is busy + aubusy /dev/shm/u 2 4553 i11 b2 hi56 + kill 4553 + sudo mount -o remount,del:../ro /dev/shm/u + kill 4560 + sudo mount -o remount,del:/tmp/4362.dir /dev/shm/u ---------------------------------------------------------------------- Here "aubusy" is the new script which issues the new ioctl. Its parameter "2" is the branch index because the process 4553 is running "sleep" on the branch 2 (/dev/shm/ro/sleep). The ino of /dev/shm/u/sleep is 11, and /dev/shm/ro/sleep is 56. The script may support the path name instead of the branch index in the future, and a option -v or something. Without -v, the script will print the PID only. > Because the process is running and there will be no lock at all, the > result may be obsoleted or bogus. But this is my current best solution. This issue remains. J. R. Okajima ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb
