[bug #24140] Painfully slow find(1) in list-permission-only AFS paths

[Daniel Richard G.]

Follow-up Comment #6, bug #24140 (project findutils):

I get your first paragraph, but I don't understand what you're responding to
in the second and third. Let me try this again:

We know what the behavior needs to be in order to avoid the
3-second-stat()s-on-AFS problem: if opendir() returns a d_type of DT_UNKNOWN
for an entry, then give up trying to determine what it is (whether -L was
given or not). However, we only want to do this on AFS, because some other
filesystems can and do return DT_UNKNOWN and yet allow us to stat() the entry
perfectly well.

The question, then, is how to make find(1) behave that way only when
needed/appropriate. I see two viable options:


1. Add a new option---let's call it "-nostatdtu", i.e. "don't stat() entries
with d_type=DT_UNKNOWN"---that goes right next to -noleaf in the man page. The
user would then give this option when slow searches in AFS-space make it
necessary.

Pros: find(1) remains filesystem-agnostic; this behavior can potentially be
used to speed up searches on other filesystems with similar d_type behavior

Cons: The option is difficult to explain to ordinary users; user has to be
aware of this option and when to use it


2. Have find(1) check each entry to see if it has a canonical path under
/afs, and if so, change to the workaround behavior.

(The value of "/afs" would be hard-coded, not user-specified, as this is
*the* non-aribitrary AFS mount point. The value might, at most, be a
compile-time option.)

Pros: Transparent to the user; a hypothetical invocation of "find /" that
goes into /afs and /brokenfs (with unreliable d_types) works correctly

Cons: Bad in the rare case that /afs isn't actually an AFS filesystem;
find(1) is no longer filesystem-agnostic


It could be 1, or 2, or both, or 2 enabled with a compile-time option, or
perhaps some other approach altogether. What would you like to see in a
submitted patch?

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?24140>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/