[OpenAFS-devel] Re: Backups using commercial products

[Sam Hartman]

    Lyle> Building a new physical filesystem is easier said than done,
    Lyle> and in any case, I'm not sure that vos dump is the most
    Lyle> performance-critical operation.  Surely there are other
    Lyle> things (read,write,fetchstatus) that would take precedence?


There are certain times when vos dump is incredibly performance
critical.  Consider situations when you need to move all data off a
server.


    Lyle> The quickest and most straightforward means of speeding a
    Lyle> single vos dump are: 1. use TCP instead of (or in addition
    Lyle> to) RX.  

What exactly would make TCP perform so much better?  Are you saying
that the performance hit is the context switching between sending
data, reading from disk and acknowledging packets and that doing part
of this in the kernel would speed things up?

It seems that you're going to have the same three basic tasks no
matter what you do--reading from disks, sending packets and dealing
with acks.  Other than the seek problems you point out, it seems that
neither of these two tasks should take particularly long.

So, does RX allow a procedure to write bytes into the queue past the
point where the window is full?  I.E. does it have a concept similar
to tcp|udp sendspace?  Shouldn't that smooth out some of the disk seek
delays?