Re: Attempt at "stat light" implementation

[jim owens <jowens@hp.com>]

Sorry our travel budget didn't allow me to be there
for the spirited discussion ;)

I don't have anything against a selective stat function
except that it adds extra conditional code that my
experience says won't be much benefit.

We have a selective getattr in Tru64 for clusters with
the same idea that it would save a lot of expensive
operations in the cluster.

It did *not*.

The problems are:

   - 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.
   - who is going to fix (and keep fixed) those gui file managers
     (and stop users from "ls -l" or viewing properties)?
   - 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.

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

So by trying to save expensive operations, it made it worse.

One practical suggestion: for fields that were not requested,
we sent back the "illegal/ignore" (usually -1) value that
could be used in a subsequent setattr.

jim