[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?


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.