xfsdump/restore? Performance ...

xfsdump/restore? Performance ...

[Linda A. Walsh]

Dunno if xfsdump/restore are considered that important with bacula being
adverted as being xfs-compat, but something I found that speeds up and
xfsdump/restore, or, especially, using xfsdump/restore to copy a file system --
I put 'mbuffer' in between them and gave it 1mb buffers, and used about 1024 of
them.  My fs->fs copy rate went up by 50%.

An equivalent amount of data took about 2700++ seconds with direction pipe from
xfsdump|xfsrestore, but with a buffer between them, that dropped to about
1800+.

Maybe xfsdump/restore need some larger buffers?  I was also thinking -- I'm not
sure how xfsrestore restores files, but does it take each file as it comes, and
then restores it, or does it cache the handles to the directories in the
previous path?  Usually wouldn't be noticeable, but if it has to walk through
directories that have lots of files, might save some lookup time.

If both were multithreaded -- with one thread for buffer management while the
other could do disk I/O -- or is that the infamous '-Y' option that has yet to
be implemented on linux? :-)

Don't know how much interest there is in these utils, but thought I'd mention
the benefit of a big buffer...  Same goes for restore and dump I presume,
separately.  I.e. if xfsdump always does output to mbuffer and mbuffer writes
to disk or to Xzip (X=g,bz,lz).  Maybe write's are sufficiently well buffered
by the kernel, that only restores would benefit -- with mbuffer reading a backup
file, but if those utils are used, there are some good possibilities for
performance improvements...

-linda


_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs