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 all. Regards, -Jeff
