Hi,
Some days ago, we were discussing the structure of the locking in FSFS.
Some people on this list like the current design, using a directory
hierarchy to represent the locks. As I pointed out, I don't like this
idea. At first, it seems elegant to use a feature of the underlying
filesystem that seem to match our needs quite well. But there are two main
problems:
We have to cope with the whole UTF-8. As Karl pointed out, this can be
solved with some kind of escaping. Now, we just have to find the right
escaping. I'm pretty sure we want to be platform-agnostic, that is, you
want to be able to lock a file in Linux, reboot into Windows and still
have it locked. So, this means escaping everything out-side of ASCII, many
non-letter ASCII characters and either upper- or lower-case leters. Why
the last one? Because else the implementation won't work on
case-insensitive filesystems (think a Windows server serving Linux
clients). Also, Windows don't like filenames like "prn", "nul", etc. very
well, so we have to protect us against that. Are there other filesystems
that have similar "quirks"? I don't know, but when we've shipped 1.2, it
will be hard to change the implementation for compatibility reasons.
The second problem is more theoretical, I hope - but I don't know. That's
the limit on pathname lengths on different OSes. Hopefully, people don't
use insanely long pathnames, so this isn't a problem in practice. Still
we're imposing the limits of the filesystem storing the repository, which
might be considered as inellegant as using the directory hierarchy for the
representation would be ellegant:-) Still, depending on the escaping
mechanism we choose (and depending on how many upperr-case letters people
have in their filenames), this *might* be problematic.
Since a patch says more than thousand words, I provide an alternative to
the current design. It uses a flat structure with names being
MD5-checksums of the absolute paths and with quasi-locks for directories.
The directory "locks" are reference counted. This isn't ready yet (as much
on the locking branch currrently), but meant for discussion only. ghudson
suggested this would be too complicated; I don't think it got much more
complicated than using directories.
The patch doesn't grab the write lock when manipulating locks. That's
necessary, but that's necessary in the current design too for OOD
checking to work properly. The patch puts locks in plae atomically, so
locks can be checked/read without holding the write lock. That's missing
from the current design and possible there too.
Some filesystems have performance problems with very many files in one
directory. As someone pointed out, using one level of directories named
by, say the first two or three characters in the filename, will solve that
problem.
Please take a look and continue the discussion:-)
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 14 01:28:48 2004