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?
I don't know the kernel code but I would sincerely look at this case.
The extra 'if's might be more expensive than just doing it.
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.
I don't think it's useful to introduce a new system call just to have
this support.
--
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-
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
