Re: Attempt at "stat light" implementation

[Oleg Drokin <green@linuxhacker.ru>]

Hello!

On Apr 7, 2009, at 11:22 AM, jim owens wrote:

>  - applications are not smart (except maybe on luster).
>  - applications find it easier and usually faster to get
>    all the stat info and sort it themselves, particularly
>    when they are tested exclusively on local systems.

No argument about these.

>  - 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.

>  - even internal kernel getattrs would often make a "light"
>    call, then the next operation needed the "heavy" attrs,
>    so we sent 2 RPCs instead of 1 and had to do a lot more
>    complicated local attr cache management of what fields
>    were valid in cache and what were not.

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.

> And I spent a lot of time fixing attr cache and cluster
> locking problems in the cluster FS and NFS code.

Well, since internally we represent only partial view of attributes
anyway, this is a not an issue for us.

Bye,
     Oleg