I would be happy to apply a debug patch.
My rational for looking for deleted files is that it may be another way
(other than modifying my rsync calls) to determine what files are being
continually held open despite rsync replacing them. Rsync's mode of
operation (as far as I know) is to copy the new file to a temporary name,
then delete the old file, then move the new file into the correct name. The
result I would think should be any open process pointing to a file which
should be marked as deleted. I only suggest this because our rsync call is
very complex. It includes many options and many excludes. Changing the rsync
calls to do one directory at a time has been tedious because the excludes no
longer work correctly the way they had been written. I have broken the test
unit several times because I did not get the excludes correct. This is not a
problem which will prevent me from continuing to troubleshoot, it is simply
inconvenient and time consuming. I do need to sync an entire filesystem,
after all.
I will continue to test, I only wanted you to understand where I was coming
from.
Also, in case I have not said it yet, Thank You very much for helping with
this issue. I appreciate it.
On Thu, Aug 14, 2014 at 1:33 PM, <[1]sf...@users.sourceforge.net> wrote:
Jacob Burkamper:
> I have thus far found it appears to be something inside /usr. I haven't
> been able to get further than that yet due to issues with my testing
> script. I am working on resolving them.
While it is a hard work, I think it is a good information to identify
the file which makes /ro busy. Please go on under /usr.
Regardless your investigation, I have a plan to write a debug patch to
print the cause of rejecting "remount,ro". If I post the patch, will you
apply and continue the test?
The patch is not to identify the file or the root cause. It is just to
identify the point where "remount,ro" returns the error.
> etc. My question then, is why /ro is being marked as busy when all files
> being accessed should be accessed via the aufs share on /? Could aufs hold
> a file or directory open itself if that file has been deleted while in use
> from underneath it?
Generally when you access /fileA via aufs, aufs finds /ro/fileA and
holds (caches) a reference to it. This cache lives until
- the memory pressure becomes tight
- the specified time passed
- explictly discard it manually
Note that deleting the file doesn't affect the lifetime of cache. Of
course, if the file is in use, it stays on cache. This is a generic
behaviour on linux (or all unixes).
This behaviour should affect unmounting the filesystem, but not for
remounting readonly.
> When fuser and/or lsof show no open files in /ro, could there be a way to
> check on / to determine what files are open but may have been replaced?
> Perhaps I need only look for processes which have file descriptors
pointing
> to deleted files.
Aufs has a debug feature to print all opened files. Try sysrq-A. But I
am not sure this is useful for this problem.
And I am not sure it is a good idea to focus the deleted files.
J. R. Okajima
--
Jacob Burkamper
CIPAFilter Development
Email:Â [2]jac...@cipafilter.com
----------------------
CIPAFilter Beta Program
Email: [3]b...@cipafilter.com
Web:Â Â Â Â Â [4]http://www.cipafilter.com
References
1. mailto:sf...@users.sourceforge.net
2. mailto:jac...@cipafilter.com
3. mailto:b...@cipafilter.com
4. http://www.cipafilter.com/
------------------------------------------------------------------------------
