From: "Linda A. Walsh" <xfs@tlinx.org>
To: xfs-oss <xfs@oss.sgi.com>
Subject: xfsdump/restore? Performance ...
Date: Wed, 11 Nov 2009 18:38:39 -0800 [thread overview]
Message-ID: <4AFB752F.2080307@tlinx.org> (raw)
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
reply other threads:[~2009-11-12 2:38 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4AFB752F.2080307@tlinx.org \
--to=xfs@tlinx.org \
--cc=xfs@oss.sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox