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

Re: Path lookup table

From: Branko Čibej <brane_at_xbc.nu>
Date: 2004-05-30 22:38:02 CEST

Greg Hudson wrote:

>On Fri, 2004-05-28 at 02:51, Branko Čibej wrote:
>> (dir-id, name, [txn-id]) -> info
>>You'll notice that I didn't spend too much time worrying about how this
>>design scales from locks/acls -- which are expected to be fairly
>>"sparse" in the tree -- to a full-blown directory index. There are some
>>tricky questions to answer; for example, I'm still not sure how to avoid
>>having to write a zillion index entries every time a directory changes,
>>either directly or through bubble-up; or how to keep the constant-time
>>nature of directory copies. It might be possible to even avoid
>>"physical" bubble-up completely. Anyway, these ruminations need a lot of
>>evolving first.
>I think it's important to answer these questions before we look at a
>table of this nature as a future direction for FS directory lookups. I
>suspect the original FS designers did consider using a separate DB
>association for each directory entry, and decided it would be too
I think that there's no question about using anything _except_ a table
for directory lookups. The only issue is optimizing the representation
of directory changes. I think we need experience with such a table
before we can finalize any kind of design, that's why I'm proposing to
start this transition and experience-gathering now.

I admit that my point of view is very (B)DB-centric, so my arguments
don't necessarily hold for FSFS -- for all I know, directory
representation may already be optimal there, so adding a path lookup
table wouldn't bring so much benefit.

Brane Čibej   <brane_at_xbc.nu>   http://www.xbc.nu/brane/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun May 30 22:40:07 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.