Thank you for this information.
I tried to detect locked branches based on the paths as mentioned below.
However I'm finding that the below algorithm does not reliably determine
the branch that a file lock is on.
>mkdir union a b
>cp /bin/sh a
>cp /bin/sh b
>mount -t aufs aufs union -o br:a
# From another shell
>union/sh
# Original shell
>mount union -o remount,prepend:b
# Now, the algorithm discussed tells us that the file lock for "sh" lock
is on "b", but it's not.
# The manual confirms that mmap files don't change branches, which is
the case with executables.
>mount union -o remount,del:a
mount: /tmp/union is busy
# Closing other shell and repeating remount confirms that "sh" was
locking branch "a"
>mount union -o remount,del:a
# No errors.
It seems to bring me back round to my prior question:
is there any way to remove one branch without affecting processes using
the other branches?
As for my examples, I apologize for changing them as we go along. I'm
just using examples as I find test cases that break.
Ultimately I want something functionally equivalent to "mount union -o
remount,del:X" which kills any processes that would otherwise cause
mount point "is busy". I haven't found out how to do this (short of the
debugging sysreq).
Lou Gosselin
On 07/26/2010 08:30 PM, sf...@users.sourceforge.net wrote:
> Lou Gosselin:
>
>> So if file "xyz" is locked and belongs to the union, I can just scan
>> each branch in order until I find either "xyz" or ".wh.xyz".
>> Then I know with certainty that this file lock is keeping this branch busy?
>>
> Generally yes. And it is better to find ".wh..wh.opq" too.
> There are some complicated cases in real world.
> For instance,
> - the file "xyz" exists only on the lower readonly branch.
> - processA
> open("xyz") for read;
> sleep(long time);
> read(from "xyz");
> - processB
> open("xyz");
> write(to "xyz");
> - processB writes to "xyz" while processA is sleeping, then the file
> will be copied-up.
> - when processA wakes up, it will notice the file is copied-up and read
> from the upper writable branch, the copied-up one.
> - if you run "remount,del:/the/lower/branch" after the file is copied-up
> but processA is still sleeping, then remount will return EBUSY. and if
> you look for "xyz", you will find the file exists on two branches.
>
> Until processA reads from "xyz", it refers to the file on the lower
> branch which keeps the lower branch busy even the file exists on the
> upper branch too.
>
> Also there are cases other than open.
> When "dirA" exists on the lower branch only, if you run "cd /aufs/dirA"
> or set inotify to "/aufs/dirA", then you will not able to delete the
> lower branch. But if "dirA" exists on the upper branch too, then you
> will able to delete it.
>
>
>
>> If everything in aufs is immediately applied to the branch (no caching
>> within aufs), then I guess this algorithm can work.
>>
>> Perhaps I assumed wrongly that aufs kept unwritten branch state internally.
>>
> Aufs has no such write-cache because the branch filesystem has generally.
> And your example "tail -f union/branch1_file" doesn't write to the
> file. :-)
>
>
> J. R. Okajima
>
------------------------------------------------------------------------------
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
