[OpenAFS-devel] Vos dump "performance"

[Harald Barth]

> This is very slow. But, is it possible that your tar command is too
> clever?

Could be. 

A test where tar can not be as clever gives me approx 10 minutes for
3131593 files and 3.8GB (5219 files/sec and 6.3MB/sec)

Still my > 2 hours are anoyingly slow. Back to what the dump seems to be doing....

I can see that DumpVnodeIndex loops over DumpVnode which calls
DumpFile which writes the data to an open RX call handle. I see some
possible optimizations/problems there:

Both DumpVnode and DumpFile do fstat. The DumpVnode only to check
against the expected file size which then can be compared to the real
file size. The DumpFile to read the file size and the blocksize. fstat
should only be called once. Not calling fstat at all (just read until
there is no more data and bail out if the number of read bytes do not
match the expected ones) is difficult as we want to know the size
before we get the data. The next operation is pread. I wonder how
pread performs compared to read.

Then I don't know if this is a good idea at all:

	/* If didn't read enough data, null padd the rest of the buffer. This
	 * can happen if, for instance, the media has some bad spots. We don't
	 * want to quit the dump, so we start null padding.
	 */

Then I have not looked if there can be further optimizations for files
with zero size.

Currently I'm wading through strace data and I have some suspicion
that these things are slow

* "random" pread without any hint to the OS what comes next
(I suspect that Linux tries to be smart and does otherwise some
readahead if you start reading all files in a directory)

Does anyone have experience from pread() compared to read()
performance? And if it matters, we're on ZFS on Linux here.

* UDP in chunks of 1444 bytes (RX)

Is that some kind of adaption to MTU (which in case of the loopback
interface is quite wrong)? Is there a way to just tell rx to use
the max UDP size and let the OS deal with the rest?

I'll be looking at how voldump behaves in comparison as well, but
first tests indicate that the slowness is there as well.

Harald.