I created an issue in the SVN issue tracker:
http://subversion.tigris.org/issues/show_bug.cgi?id=3335
>
> 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-26 13:13:10 CET