Lou Gosselin: > Yes, but it lacks sufficient information to identify the exact > process(es) blocking the operation.
Then let's think about the sufficient info. You might remember my old reply. ---------------------------------------------------------------------- Do you mean that you want to find the "tail" process accessing "branch1_file", ie. want to make sure that "union/branch1_file" exists in branch1 but "branch2_file"? For such case, people runs "ls branch1 branch2" usually. In old aufs1 era, there was a script called "unionctl" which has a query operation. If you run "unionctl --query1 branch1_file", it shows "branch1". ---------------------------------------------------------------------- For simple cases, I think it should work even for you. - remount,verbose,del failed due to some files are still in use and prints the filename. - lsof tells you the processes which are opening the aufs files. - compare these two filename lists. - ls/find for the result filename in the branch you want to delete. This is a simple name baed matching solution. Do you agree this solution will work in simple cases, or are you still unsatisfied? 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. - 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. - 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. By the way, you might misunderstand lsof. The utility scans /proc/*/fd or fdinfo and shows info, instead of send a query to FS. What I want say here again is FS doesn't (and should not) have info about processes. If you already know about it, just ignore please. > I have tried this already from a prior email. Your right lsof doesn't > show it, but on the other hand inotify does not appear to lock the file > system in the first place. Or at least I haven't been able to produce > such a scenario. Just now I tested ext2+inotify and was able to unmount > it without issue. 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 ------------------------------------------------------------------------------ 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
