[OpenAFS] Re: Performance problems seem to be coming back

[Andrew Deason]

On Mon, 12 Sep 2011 11:31:56 -0400
Dale Pontius <pontius@btv.ibm.com> wrote:

> Maybe I'm missing what rxdebug really does, but I think it sounds just
> about perfect.  I presume that the OpenAFS clients and servers have
> packet queues for moving data, and rxdebug just drops packets into
> those queues like any other part of afs.  If the other parts of afs
> queue are in "distress" for whatever reason, all of the other packets
> in that queue will share in the distress, including my rxdebug
> requests.  In this case, that's what I want - to be told about
> "distress" between the server and me, and for the first approximation
> I'm not too concerned about the reason, just that it exists.

There are a large number of reasons an AFS fileserver will not properly
service a request from a client; none of the "ping"s we've discussed
will catch them all. What Jeffrey said will cover most of it, but if you
want to test "will the fileserver give me data", then your "ping" should
be asking the fileserver for some data through that client.

If you want to test "will the fileserver give anybody data", you can use
the afsio and afscp tools to do a one-shot read-the-file operation on a
file you already know to exist.

But if the existing rxdebug -version is detecting what you want, then
fine, just use that. By making a more ping-like tool, I meant, having it
report dropped packets, RTT, etc (right now it doesn't tell you at all
what's going on). What it actually does on the wire is already fine for
testing Rx stack availability.

-- 
Andrew Deason
adeason@sinenomine.net