[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: modify chmod

From: jeff.liu
Subject: Re: modify chmod
Date: Sun, 21 Feb 2010 22:47:34 +0800
User-agent: Thunderbird (X11/20080505)

Jim Meyering wrote:
> jeff.liu wrote:
>> Jim Meyering wrote:
>>> jeff.liu wrote:
>>>> Hi Jim,
>>>> Thanks for your so detailed instruction! And sorry for my later response, 
>>>> I just back from travel.
>>>> Could you please check my comments inline?
>>> ...
>>> This is the most important point:
>>>>> [*] This change is intended to be an optimization.
>>>>> I am leery of letting an optimization change the semantics of a
>>>>> program like chmod (which is already very efficient), even if only
>>>>> for the unusual case of a bind-mounted ACL-possessing non-directory
>>>>> that resides on an NFS-mounted file system.
>>>>> Other opinions?
>>> Considering that this optimization is possible only
>>> if we agree to degrade (even by only a small amount)
>>> chmod's correctness, I am inclined to drop it.
>> so you means this optimization is acceptable only if we can ignore the 
>> correctness for the
>> bind-mounted files?
>> but you think it is no properly since it will affect the semantics of chmod?
> Hi Jeff,
> That's right.
> If someone measures the performance difference and
> we find it compelling enough that we're willing to overlook
> the incorrectness with (admittedly rare) bind-mounted ACL-possessing
> non-directories, this might be worthwhile -- via a new option.
> It must not be the default, since it can constitute a real regression.

> Chmod is typically quite fast, even for large hierarchies.
> Since the value of the performance improvement is less when
> enabled only via an option, it becomes harder to justify
> the added complexity.

Hi Jim,

Thanks for your clarification.
I have learn a lot from your guys even if the patch does not acceptable after 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]