On 16.02.2012 16:46, C. Michael Pilato wrote:
> On 02/16/2012 05:50 AM, Branko Čibej wrote:
>> On 15.02.2012 21:18, Greg Stein wrote:
>>> And thinking on that: how does the client do inheritance in a
>>> mixed-revision working copy? D_at_10 inherits props from P, but the
>>> client has P_at_5. If there are changes in P_at_7, then the inherited
>>> properties a likely wrong for D_at_10.
>> Reading this thread really makes me wonder a bit... How can anyone even
>> contemplate implementing inheritable properties on the client side? A
>> server-side implementation of (strictly versioned!) inheritable props
>> would not require any new logic on the client, and it's the only way to
>> make such a thing work without expecting weird behaviour with different
>> client versions. I'd have thought that the mergeinfo saga would have
>> been enough of a reality check.
>>
>> Regarding upwards searches and "bounded reads" ... anyone who believes
>> reading a datastore is cheap should try to write a fast, data-intensive
>> GAE application. :)
>>
>> IOW, I completely agree with Bill Tutt's assesment and Greg's arguments.
>> Please try to understand the issues before assuming things.
> Perhaps if those boasting of said understanding would invest the energy to
> take this conversation a bit farther than merely "that won't work", and
> maybe explore the "but this might..." space a little more deeply and
> publicly, the ambient level of understanding all 'round would increase, and
> gosh, we might even see some real progress on this feature.
Hasn't it all been spelled out yet? We know that (a) lookups are
expensive, (b) tree walks are expensive, (c) RPCs are expensive.
Therefore, any design should try to minimize all three. I already posted
a suggestion about how to speed up lookups by reducing the number of
tree walks; and if we follow that design and the hint about ACL
inheritance in NTFS (namely, populate the subutree with explicit values
or at least single-indirection pointers to explicit values instead of
calculating the inheritance tree at every lookup), we'll also reduce the
number of datastore accesses (~~ RPCs ~~ I/O operations), thus reducing
the cost of /every/ FS implementation.
So I shot my mouth off a bit but we've known for /years/ where the
bottlenecks are in the FS design -- as exemplifed by the fact that we
dared not turn on directory deltification until recently because it
hosed performance. As Greg points out, caching is just papering over
poor design. The current design is what it is for lots of reasons, so
I'm not pointing fingers here; but there's nothing wrong with
recognizing its faults and fixing them.
-- Brane
Received on 2012-02-16 18:32:33 CET