Re: NFSv4/pNFS possible POSIX I/O API standards

[Andreas Dilger <adilger@clusterfs.com>]

On Dec 15, 2006  14:37 -0800, Ulrich Drepper wrote:
> Andreas Dilger wrote:
> >IMHO, once part of the information is optional, why bother making ANY
> >of it required?  Consider "ls -s" on a distributed filesystem that has
> >UID+GID mapping.  It doesn't actually NEED to return the UID+GID to ls
> >for each file, since it won't be shown, but if that is part of the 
> >"required" fields then the filesystem would have to remap each UID+GID
> >on each file in the directory.  Similar arguments can be made for "find"
> >with various options (-atime, -mtime, etc) where any one of the "required"
> >parameters isn't needed.
> 
> The kernel at least has to clear the fields in the stat structure in any 
> case.  So, if information is easily available, why add another 'if' in 
> the case if the real information can be filled in just as easily?


The kernel doesn't necessarily have to clear the fields.  The per-field
valid flag would determine is that field had valid data or garbage.

That said, there is no harm in the kernel/fs filling in additional fields
is they are readily available.  It would be up to the caller to NOT ask
for fields that it doesn't need, as that _might_ cause additional work
on the part of the filesystem.  If the kernel returns extra valid fields
(because they are "free") that the application doesn't use, no harm done.

> >I used to think this also, but even though Lustre supplies d_type info
> >GNU ls will still do stat operations because "ls --color" depends on
> >st_mode in order to color executable files differently.
> 
> Right, and only executables.
> 
> You can easily leave out the :ex=*** part of LS_COLORS.

Tell that to every distro maintainer, and/or try to convince the upstream
"ls" maintainers to change this. :-)

> I don't think it's useful to introduce a new system call just to have 
> this support.

It isn't just to fix the ls --color problem.  There are lots of other
apps that need some stat fields and not others.  Also, implementing
the compatibility support for this (statlite->stat(), flags=$all_valid)
is trivial, if potentially less performant (though no worse than today).

Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.