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.
   I have double and triple checked now, there is nothing in our filesystem
   other than the rsync command which directly touches /ro. Certainly, there is
   no process which is pointing at /ro directly for configuration files, 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?
   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.

   On Mon, Aug 11, 2014 at 10:55 PM, <[1]sf...@users.sourceforge.net> wrote:

     Jacob Burkamper:

   > I will collect the rest of the the information and get back to you.

     I had better explain what I am thinking. Here is the plan in my mind.
     - identify the file which makes /ro busy.
     - the file may not be single.
     - since rsync as a process already terminated, rsync itself cannot make
     Â  /ro busy.
     - there may exist other process(es) related to rsync or the identifed
     Â  file.
     - generally rsync communicates with the daemon. but your case doesn't
     Â  have a remote side. so there should not exist the rsync daemon
     Â  process.
     - by setting udba=notify to aufs and auctually modify the files
     Â  bypassing aufs, the notify events fired internally and aufs starts
     Â  handling the event asynchoronously. But this handling should not make
     Â  /ro busy.
     Currently I don't know what makes /ro busy. The purpose of this
     investigation is to make it clear.
     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/
------------------------------------------------------------------------------

Reply via email to