Re: Subdirectories for db/revs/* on fsfs backend

Mark Benedetto King wrote:
> I am opposed to hashing strategies that create a big forest of directories
> (a.k.a. wasted inodes) and make it difficult for humans to quickly find
> particular files. Also, deep hierarchies introduce additional filesystem
> load in terms of directory inode traversal, etc.

What I have done in the past was a simple prefix scheme (abc/def/abcdefghi.ext)
which

1) only creates the intermediate directory when a file with that prefix needs to
be stored (no wasted inodes);

2) is always/only two levels deep;

3) is human readable (since you can find the file based solely on the filename).

I'm not particularly tied to this scheme, though; just wanted to point out that
a good design can meet all of your criteria.

A scheme like this would have to be modified to fit the filenames used to store
the revs, though, to make sure that the hashing was evenly distributed. My
actual use case is special; since I am storing JPG's based on ISBN numbers, I
could do 123/4567/123456789X.jpg and all of a given publisher's images appear in
the same folder(s).

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org