Re: xfsdump -s unacceptable performances

[Bill Kendall <wkendall@sgi.com>]

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
>    filesystem

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.

Regards,
Bill