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
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
