On Mon, Sep 12, 2005 at 10:42:23AM -0700, Bryan J. Smith wrote:
> Bill Kendall <wkendall@xxxxxxx> wrote:
> > Try the dump this way and see if performance improves:
> > xfsdump -J -f /dev/nst0 -b 1048576 -d 8192 /raid
>
> Agreed. Play with the blocking/buffering options of xfsdump
> itself.
>
My 2 cents FWIW.
The -d 8192 means that the media files are around 8192Mb
i.e. they are big and should be less of them.
Each media file is a contained unit and repeats a header with
directories and inode map, and that is why having fewer media
files will mean less data to dump (and less redundancy).
One can also use the -S option to use just one media file.
If one actually dumps to a file or stdout then it always uses
one media file as I guess it thinks the redundancy for tape
is not needed.
Unfortunately AFAIK, the threaded part of xfsdump on Linux is
not there (it is on IRIX with sprocs).
What this means is that one can not specify multiple tape devices,
and also that a helper thread which operates on a ring buffer
(defaults to 3 bufs - number changed by -Y and pinned by -P)
is not used to separately talk to the device.
So I was going to mention its benefit and then realised it
wasn't on Linux. Sorry.
Another note is that Kai Makisara (st driver guy) once mentioned (6/Apr/2004)
that larger buffer sizes are not necessarily a good thing:
"The other problem is that you probably would like to use direct transfers
between the xfsdump/xfsrestore buffer and the drive instead of using the
"bounce" buffer in the driver. This is not possible unless the tape
requests are small enough for the SCSI adapter. In your case the limit is
96 pages. You can try to increase this limit but it is not a general
solution.
I would recommend xfsdump/xfsrestore to use smaller requests if possible.
64 pages of 4 kB would make 256 kB. Using this request size should not
limit throughput even with the fastest tape drives."
--Tim
|