On Thu, Feb 16, 2012 at 12:31 PM, Branko Čibej <br...@apache.org> wrote: > 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@10 inherits props from P, but the >>>> client has P@5. If there are changes in P@7, then the inherited >>>> properties a likely wrong for D@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.
Hi Brane, So it's safe to say that barring a redesign of the backends you believe that inheritable properties are a non-starter? This wouldn't be something I could tempt you to assist with is it? Paul > 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
