On 08/20/2010 05:56 AM, sf...@users.sourceforge.net wrote:
> This is a simple name baed matching solution.
> Do you agree this solution will work in simple cases, or are you still
> unsatisfied?
>    
Yes, for some simple cases this did work.
> For other cases, even lsof will not help you or you need to know the
> behaviour of your system or processes.
>    
> - the name exists under several different dirs
>    Since remount prints the filename only without the preceding dirs, you
>    may not distinguish when ls/find tells you there are several same
>    named files on the branch.
>    If you know the behaviour of your processes well, it will be good help
>    to choose one. If it is not suffecitne still, then info from Magic
>    SysRq will be helpful a little since it prints the parent dir name
>    too. As long as the file is not deleted, the inode number will help
>    too. (if you need such number, I can add it into the messages from
>    remount)
>    This is a path-based or inode number-based matching solution.
>    

There are a few reasons I haven't seriously considered using the sysreq, 
even though it might work.
1. It requires compiling in debug mode.
2. The manual warns of performance degradation under debug mode.
3. The syntax of the debugging output is complex, parsing may not be 
very reliable and it could change.
4. Under debug mode, aufs operations generate several kbytes of logs. 
These can be filtered out, but it shouldn't be necessary.

If you tell me debug mode is how it *should* be done, then I'll 
reconsider it.
> - the name exists on several different branches
>    For example, you have written the similar case of sh on the branch a
>    and b. Remember?
>    In your a/sh and b/sh case, if you know the order of
>    + invoking union/sh
>    + prepending the branch b
>    then you will be able to distinguish a/sh and b/sh. Won't you?
>
>    This case can be more complicated. For exmaple, invoke union/sh again
>    after prepending the branch b, then you have two sh processes and
>    remount prints only sh. It may not be good for you to keep remembering
>    what you did in the correct order. And even if remount print the inode
>    number, you will not be able to distinguish two running shells since
>    you don't have the way to get the inode number of running executable
>    file.
>    While I guess this is rare, if this is your major concern, then I
>    agree with you that you cannot determine the process unless you
>    remember the order of what you did.
>    
I'd need to do tests to see if I could break the above heuristic. I'm 
thinking it's still fallible because we don't know when a process has 
opened a file. Or a process may have opened a file but not mmaped it 
right away. At the very least I imagine there's a race.

> - opened file but deleted (or renamed)
>    While lsof will tell you the filename, but you cannot ls/find the
>    filename in the target branch. If you can find the name, the file must
>    be different from the one which makes the branch busy. Probably it is
>    the newly created same named file after the deletion of original one.
>    In this case, the inode number based solution (above) will be
>    helpful. But you may need to know the behaviour of the process.
>    
> - current working dir (or any other dir in use)
>    If a process's cwd is in the target FS, you cannot unmount it
>    generally. You will need to scan /proc/*/cwd or somwthing, or lsof
>    will help you.
>    In aufs, if the dir exists in the target branch only, then remont,del
>    will fail. If the dir exists in any of other branches, it will
>    succeed.
>
> There may happen other cases, but I am not sure. I am afraid that I
> forgot those issues now. But I tried describing as far as I remember
> now.
> I was wrong, sorry.
> inotify always handles the umount event and it will not keep FS busy.
> In aufs, inotify can be one reason to block deleting a branch. In this
> case, remount prints the inode number instead of the filename.
>
>
> Sorry again for long mail.
> But I think I should describe details to be understood well.
>
>
> J. R. Okajima
>    


I cannot predict what users will do. All the solutions to date have been 
heuristic recreations of aufs internal state. Unfortunately, probability 
based heuristics are not at all useful to me since they're shots in the 
dark. The need to automate this is crucial since this is a standalone 
box operated by users. In terms of user expectations, the umount 
operation should be deterministic: either the entire server goes down, 
or just the branch being unmounted goes down. It's a shame to have to 
bring down the whole union when just one branch needs to be 
disconnected, but that's what we currently have.

I cannot push out a solution having non-deterministic behavior with 
regards to killing processes. Users would consider that a bug, and would 
expect a bug fix. It was in this light that this email thread was begun.

At this point I feel we've exhausted the topic. I've put my case 
forward; if you still don't see the need to expose the internal branch 
lock state, I'll respect your decision.

Lou Gosselin


------------------------------------------------------------------------------
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 

Reply via email to