Re: xfsdump -s unacceptable performances

["Daniele P." <daniele@interline.it>]

On Wednesday 16 August 2006 18:38, Bill Kendall wrote:

Hi Bill,
Thanks for the explanations. I only have had a glimpse into the sources.

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

Yes, but scanning 10.000.000 inodes when you really need to scan only 4 it's
really a waste of resource.
This is a corner case. But usually I want to backup only 10% of the entire
filesystem.
At this point I have to redesign my backup strategy taking care of
xfsdump strength and weakness.

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

That's interesting.

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

This too, but for me the xfs filesystem it's a big black box.

Thanks again,
Daniele