[Top] [All Lists]

Re: xfsdump -s unacceptable performances

To: "Daniele P." <daniele@xxxxxxxxxxxx>
Subject: Re: xfsdump -s unacceptable performances
From: Bill Kendall <wkendall@xxxxxxx>
Date: Wed, 16 Aug 2006 11:38:06 -0500
Cc: xfs@xxxxxxxxxxx
In-reply-to: <200608161515.00543.daniele@xxxxxxxxxxxx>
References: <200608161515.00543.daniele@xxxxxxxxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Mail/News 1.5 (X11/20060228)
On 08/16/06 08:15, Daniele P. wrote:
Hi all,
I'm new to the list. I have a problem with xfsdump using the -s option.
I'm aware that the latest version (2.2.38) skip the scan and prune of
the entire filesystem (see the test below), but there are other places
where xfsdump performs an entire scan of the filesystem, slowing down
the backup process.

For example in:
 * dump/inomap.c after "phase 3" there is a function call to
   bigstat_iter that scan the entire filesystem

This scan stops after determining start points for all streams.
On Linux there's always one dump stream, so it returns after
reading one buffer full of inodes.

 * dump/content.c the function dump_dirs again scan the entire

And of course there's another scan for dumping the non-dir inodes.
Keep in mind these are inode scans, which are substantially faster
than recursing through the directories doing individual stat(2) calls.

Nonetheless, these scans could be optimized by seeking the scan to
the next inode of interest, which could be found using xfsdump's inomap
(created in the first scan). This would be beneficial to -s and
incremental dumps.

Are all there scan really necessary?

A lot of this stuff could be done in a single scan in a disk-to-disk
backup approach. But in the current scheme, they are necessary.

Could we expect a performance fix?
Is there a workaround?

Nothing is planned, but patches are always welcome.


<Prev in Thread] Current Thread [Next in Thread>