On Mon, Feb 27, 2012 at 6:33 PM, Branko Čibej <brane_at_apache.org> wrote:
> On 28.02.2012 00:20, Paul Burba wrote:
>> On Thu, Feb 16, 2012 at 12:31 PM, Branko Čibej <brane_at_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_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.
>> Hi Brane,
>>
>> So it's safe to say that barring a redesign of the backends you
>> believe that inheritable properties are a non-starter?
>
> I merely agree that true inheritance, as opposed to faked-on-write
> inheritance, is going to be a problem any way you look at it. And it's
> not a complete redesign of the backends, "just" the representation of
> directories, that would improve not only inherited properties but solve
> quite a few performance (and size) issues, IMO.
Hi Brane,
I confess I don't fully understand all of your suggestions, nor all of
the objections that have been raised thus far. In an effort to better
understand I'm creating an experimental branch to work on some of my
ideas re inheritable properties and hopefully I'll find my way to a
better understanding of your concerns.
>> This wouldn't
>> be something I could tempt you to assist with is it?
>
> I'm afraid temptation isn't the issue ... lack of time is. Besides, my
> boss reads this list and it'd look funny if I produced more code here
> than at $JOB. :-P
I figure as much, but it never hurts to ask!
Paul
Received on 2012-02-29 17:16:12 CET