Could you do some rxdebug calls to the fileserver next time? So we know why it's getting unresponsive. It could be running out of threads. I don't expect that, but it could be ...
The 'symptoms' seem to be, for the most part, volume-specific. Slow response to accessing that volume, followed by the clients seeing a timeout on it. So, guts-o-the-fileserver folk, is there a volume- wide lock that gets set by a particular fileserver thread when it's being acted upon? Since deleting a whole-bunch-of-files (a /bin/rm - fr <dir>) is happening, that's a whole lot of requests coming in in- series to that volume, being taken care of on (probably) a first- come, first-served basis, leaving little room for other clients to get an op in on that volume?
... or it could be delayed by the filesystem underneath and that's the case where we can't do anything about it.
Things look ok on that end. -rob _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
