[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Proposal: Improved locking implementation for fsfs

From: Peter N. Lundblad <peter_at_famlundblad.se>
Date: 2004-12-23 22:57:45 CET

On Wed, 22 Dec 2004, [UTF-8] Branko Ä^Libej wrote:

> Peter N. Lundblad wrote:
>
> >On Mon, 20 Dec 2004, Brian W. Fitzpatrick wrote:
> >
> >
> >
> >>This proposal sticks with the current mechanism of using the
> >>filesystem as a tree to store the locks themselves, and the
> >>lock-tokens (which merely contain a pointer to the lock) are all
> >>stored in one directory, keyed on their token/uuid.
> >>
> >>
> >>
> >Just for the record, we discussed the lock-tokens storage further on IRC
> >and agreed that we should use a one-level hierarchy, using the first few
> >bytes of the lock-token to spread these files in directories. This helps
> >filesystems with problems having many files in one directory. Using two
> >characters gives 256 directories in the worst case. That seems to be a
> >reasonable balane between many files in one directory and one directory
> >per lock token. We don't expect millions of locks, do we?
> >
> >
> Not "expect", no, but we've been burned before where we based out
> implementation on something we thought was a reasonable common case,
> then it turned out people were doing something quite unreasonable (such
> as, e.g., putting 50000 files in one directory).
>
> So I'd suggest using a scheme that scales slightly better, unless that's
> really a huge pain to do.
>
Maybe. Any suggestions? Rehashing? Not very funny in the file system. One
more character? Gives 4096 directories and about 10 million files with
reasonalbe directory size. Or, anything else?

Thanks,
//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Dec 23 22:59:05 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.