On Dec 06, 2006  09:42 -0800, Ulrich Drepper wrote:
quoted text
> Rob Ross wrote:
> >File size is definitely one of the more difficult of the parameters, 
> >either because (a) it isn't stored in one place but is instead derived, 
> >or (b) because a lock has to be obtained to guarantee consistency of the 
> >returned value.
> 
> OK, and looking at the man page again, it is already on the list in the 
> old proposal and hence optional.  I've no problem with that.

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.

I don't think it is _harmful_ to fill in unrequested values if they are
readily available (it might in fact avoid a lot of conditional branches)
but why not let the caller request only the minimum information it needs?

quoted text
> >I can't speak for everyone, but "ls" is the #1 consumer as far as I am 
> >concerned.

That is my opinion also.  Lustre can do incredibly fast IO, but it isn't
very good at "ls" at all because it has to do way more work than you
would think (and I've stared at a lot of straces from ls, rm, etc).

quoted text
> I think this is more a user problem.  For normal plain old 'ls' you get 
> by with readdir.  For 'ls -F' and 'ls --color' you mostly get by with 
> readdir+d_type.  If you cannot provide d_type info the readdirplus 
> extension does you no good.  For the cases when an additional stat is 
> needed (for symlinks, for instance, to test whether they are dangling) 
> readdirplus won't help.

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.  Since virtually
all distros alias ls to "ls --color" this is pretty much default behaviour.
Another popular alias is "ls -F" which also uses st_mode for executables.

$ strace ls --color=yes		# this is on an ext3 filesystem
:
:
open(".", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 3
fstat64(3, {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
getdents64(3, /* 53 entries */, 4096)   = 1840
lstat64("ChangeLog", {st_mode=S_IFREG|0660, st_size=48, ...}) = 0
lstat64("install-sh", {st_mode=S_IFREG|0755, st_size=7122, ...}) = 0
lstat64("config.sub", {st_mode=S_IFREG|0755, st_size=30221, ...}) = 0
lstat64("autogen.sh", {st_mode=S_IFREG|0660, st_size=41, ...}) = 0
lstat64("config.h", {st_mode=S_IFREG|0664, st_size=7177, ...}) = 0
lstat64("COPYING", {st_mode=S_IFREG|0660, st_size=18483, ...}) = 0
:
:

Similarly, GNU rm will stat all of the files (when run as a regular user)
to ask the "rm: remove write-protected regular file `foo.orig'?" question,
which also depends on st_mode.


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

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html