J R, > > You are misunderstanding. > When union/sh was invoked, there were only one branch in union and only > one real file "sh" in union. This only one real file was mmap-ed and > executed. The description in the manual means that the mmap-ed file on > the branch "a" will never be refreshed and changed to the branch "b". >
I believe I do understand whats happening, and I have no problem that "union/sh" locks branch "a" and not "b". That's just the way aufs works. The problem I do have, and the problem I'm trying to explain, is that I need to kill whatever processes are causing file locks on a specific branch, but I cannot identify them. I said: "To do a '-o del:X', doesn't one have to kill all file locks on the union, even those which aren't blocking X?" You said: "Of course, the answer is no. Usually 'lsof' is enough for such case I think, because users can find which file exists in which branch easily." However, as shown in last email, knowing which file is causing the lock is insufficient because mmaped files could be sourced from any branch. There are of course many scenarios which could cause this: copy-up, file unlink, remount prepend, etc. So, in the case of mmaped files, is it possible to tell if such locked files are actually blocking branch X (without debug sysreq)? If not, consequently there can be no 100% reliable script to kill only those processes which are blocking X, prior to issuing aufs remount options. It seems the only way to be positive an aufs remount will work is to kill all the file locks on the union, but I was wanting to hear it from you first before making that conclusion. Lou Gosselin ------------------------------------------------------------------------------ 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
