[OpenAFS-devel] Re: Backups using commercial products

[Lyle Seaman]

Sam Hartman wrote:

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

True, true.

> 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?
>

Yes, and the copyin/copyout overhead, and the fact that most (all?)
vendors'implementations of TCP have improved a great deal through
the years, and are much more efficient users of CPU and memory
bandwidth than is RX.

> 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.
>

One would just as soon not copy the data around in memory, but let
the ethernet driver DMA it out of the filesystem cache.  RX has improved
in this regard, but still copies things around too much.

> 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?

No it doesn't have any such thing, nor an equivalent to sendfile().
 Those
sorts of things would help, but why reinvent them?  And they wouldn't
help
much with the disk seek delays. The only way to minimize the effect of
the
disk seeks is to batch up more I/O at one time.

John M, is there any reason that the order of the volume dump contents
needs to match the order of the large/small vnode lists?  I can't think
of
any reason, but then, I never have understood that code.