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