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

[Daniel Richard G.]

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

Hmm. So looking at d_type by itself yields normal directories, but not mount
points, or directory symlinks. Symlinks aren't such a big deal, but I notice
that even though mount points read as DT_UNKNOWN, you can still stat() them.
Not that it does you much good when you're scanning zillions of entries.

(Part of the goal here is to allow find(1) to search through l-only-space
quickly, so that it can find directories where it has read access. I suppose
not recursing through mount points is the price to pay for avoiding stat()
calls.)

I see that when the process has read access, you still get DT_UNKNOWN for all
non-normal-directories. (You can't "fs examine", but you can stat() just
fine.) Is this something that could be addressed on the AFS side? This would
allow find(1) to determine that it has AFS read access to the directory
without calling an ioctl, which would be splendid.

Thanks for confirming my suspicion with regards to throttling on the server
side; I had wondered whether that was intentional.

I didn't mean to suggest that the issue is timing-related---only that network
latency might make "ah, the server is dragging its feet on this stat() call"
and "is everybody in my neighborhood using Bittorrent right now?" difficult to
tell apart :-)

Finding a cell with a suitable path should be possible then, but I was making
the point that even if a solution is developed with that, you won't end up
with a nice, self-contained rig for doing regression testing after the fact.
Emulating the behavior lets you dispense with all the infrastructure you'd
otherwise need. (The only remaining question is to what extent are AFS ioctls
and such needed, since a compile-time switch is obviously going to be a hurdle
for most folks.)

    _______________________________________________________

Reply to this item at:

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

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