On Tue, 25 Nov 2008, Jaan Vajakas wrote:
> Thank you for your investigation!
>
> Is it specified by a standard what a file system should do if a process
> wants to delete an open file? If not, then it seems to me that the way
> svnadmin behaves (deleting an open file) is dubious because it is not
> intuitively clear what the file system should do (on the other hand,
> renaming the file to .fuse_hiddenXXXXXXXXXX is rather counterintuitive,
> too).
svnadmin is ok specification but not security, reliability,
"interoperability" wise though FUSE and/or NTFS-3G could be
blamed as well for this problem.
> I hope this issue gets straightened up because it is annoying when such
> things turn out unexpectedly (even if there are easy workarounds, as is
> the case with this bug).
Please forward the issue to the SVN developers (bug tracking, etc),
probably they could fix it easily.
Regards,
Szaka
> > Ok, the issue is a bit subtle.
> >
> > To make it short, you could upgrade to at least kernel 2.6.26 and
> > NTFS-3G will work blazing fast: less than a second, like it does
> > for me.
> >
> > The long story: the BDB fs-type uses mmap which is supported by all
> > FUSE based file systems since only 2.6.26 kernels. When this failed
> > then svnadmin started the cleanup process and this is when things
> > fell into an infinite loop due to how repos/locks/db.lock is used
> > in svnadmin and how FUSE handles removed but still open files:
> >
> > open repos/locks/db.lock
> > ...
> > while repos/locks non-empty
> > remove all files
> > ...
> > close repos/locks/db.lock
> >
> > When a file in use is removed, like db.lock, then the high-level
> > FUSE API (what currently NTFS-3G also uses) renames the file
> > to .fuse_hiddenXXXXXXXXXX. The directory won't be empty until
> > all file handles/references are closed ==> infinite loop. That's
> > why both NTFS-3G and svnadmin used the CPU.
> >
> > Potential solutions :
> >
> > 1. svnadmin could(?) use 'if' instead of 'while' above.
> >
> > 2. svnadmin could(?) close the db.lock before the while loop.
> >
> > 3. db.lock could be outside of the repos/locks directory.
> >
> > 4. Some other lock solution (locking itself works absolutely fine
> > with all FUSE file systems, even without explicit support).
> >
> > 5. FUSE could be fixed (I very much doubt because the low-level
> > interface solves this issue and it would be far from trivial).
> >
> > 6. NTFS-3G could move to the low-level FUSE API which will do
> > happen but that will take years.
> >
> > Btw, this scenario affects all high-level FUSE file systems,
> > NFS and probably other network file systems too.
> >
> > Regards, Szaka
> >
> > --
> > NTFS-3G: http://ntfs-3g.org
>
--
NTFS-3G: http://ntfs-3g.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-11-25 23:38:18 CET