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