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

[Jeffrey Altman]

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

Daniel:

I'm not sure there is anything to fix from the AFS side.  The problem that is
being faced is that the process does not have the ability to read status data
about the objects in the directory.  All AFS provides is the name. 
Directories can be determined by the vnode having an odd value so the client
is able to set that value for directory objects.  However, any vnode with an
even value could be a mount point (which should appear as a directory), a file
(which should not), or a symlink (which can appear as either depending on what
it refers to).  The client therefore has no ability to set the type of an
object in a status query when the process has no read permission.  Therefore,
the d_type is set to DT_UNKNOWN.  The type truly is unknown.  To interpret
this as "not a directory" would be incorrect.  In the AFS case, d_type ==
DT_UNKNOWN really means "access denied".

I suspect that the slow down you are seeing is caused by throttling on the
file server when a client continuously sends FetchStatus requests which end in
an Access Denied error.  After N RPCs that end in an error the file server
begins to throttle the client to prevent it from DoS attacking the server.

Can you explain why you believe the issue to be timing related?

As for there not being public cells that export directories with
"system:anyuser l" ACLs assigned, there are plenty of them.  Finding an
example case would not be hard and even if it were hard, putting up a test
volume with such a case in the grand.central.org or your-file-system.com or
andrew.cmu.edu or ir.stanford.edu or athena.mit.edu cells would be trivial to
do.

Jeffrey Altman




    _______________________________________________________

Reply to this item at:

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

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