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
>inefficient.
>
>
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