Re: Attempt at "stat light" implementation

[jim owens <jowens@hp.com>]

Oleg Drokin wrote:
> On Apr 7, 2009, at 11:22 AM, jim owens wrote:
> 
>>  - who is going to fix (and keep fixed) those gui file managers
>>    (and stop users from "ls -l" or viewing properties)?
> 
> The idea is once this gets upstream, ls (and then possibly
> filemanagers) will start to use this call.
> Then it will eventualy propagate to users the natural way.

you can lead them to water, but can't keep them from peeing in it :)

> The thing is, e.g. in Lustre there are different kind of locks you
> would get for different inode attributes and these 2 RPCs to
> get them separately 5 minutes apart from each other would actually
> save us some RPCs, since there would not be lock ping pong to
> invalidate the locks held by a client protecting e.g. directory
> nlink count (that the client does not care about) when another dir
> is created in that dir.

I would have been happy with more RPCs if we even got 10 seconds
of extra time on our shared lock before doing the invalidate and
switch to the exclusive heavy attr lock.  It was all the heavy
calls at subsecond intervals after the light ones that really
hurt.  But if you start seeing that kind of traffic I guess you
can always code it to change light requests to heavy ones and
cache them.

jim