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).
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).
Best regards,
Jaan
> 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
---------------------------------------------------------------------
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:37:54 CET