Hi Dave,
Thanks for the info. Too bad RH didn't backport the functionality into RHEL6 (which is on
maintenance support phase 2 for 2017-2020).
> I don't think multiple dump streams does what you want.
> When you create multiple dump files with a current xfsdump, you also
> need to supply xfsrestore with all those dump files, too, otherwise
> the dump inventory cannot be validated. IOWs, I don't think you can
> just restore a single dump file from a multi-stream dump as data
> being restored may be spread across multiple dump files...
I had tested this and it completed successfully, with no warnings or errors:
xfsrestore -R -r -p 30 -f /mnt/tmp/dumps/l0/file1 /mnt/dst
xfsrestore -R -r -p 30 -f /mnt/tmp/dumps/l0/file2 /mnt/dst
# etc.
My test case was relatively simple though. (Also, the restore was done on a newer CentOS7 system).
It seemed that doing it in this way with the cumulative (-r) and resume (-R) options is valid, but
maybe that is just my interpretation of the xfsrestore man page. If it is not valid, it would be a
useful functionality to have.
Anyway I will come up with an alternative approach.
Thanks,
-rt
--
Ryan Taylor
Research Computing Specialist
Research Computing Services, University Systems, University of Victoria
On Tue, 2018-04-17 at 16:59 +1000, Dave Chinner wrote:
> On Tue, Apr 17, 2018 at 03:08:45AM +0000, Ryan Taylor wrote:
> >
> > Hello,
> >
> > I have a CentOS6 system with kernel 2.6.32-696.23.1.el6.x86_64 and xfsdump-3.0.4-
> > 4.el6_6.1.x86_64
> > (the latest available versions).
> >
> > When I try to xfsdump I get this error:
> >
> > $ sudo xfsdump -d 2000 -l 0 -p 30 -L Dump -f /mnt/data2/l0/file0 -f /mnt/data2/l0/file1
> > /mnt/data1
> > xfsdump: too many -f arguments: maximum is 1 when running in miniroot
>
> Your xfsdump binary is so old it doesn't support multiple dump files
> (or streams, as xfsdump calls them). That was introduced in v3.1.0,
> IIRC, via commit:
>
> commit 7ffdf9d1fbd65eb38171b8772ed4c31315cbbef6
> Author: Bill Kendall <wkendall@xxxxxxx>
> Date: Mon Nov 7 14:58:31 2011 -0600
>
> xfsdump: enable multiple streams
>
> IRIX contained an environment referred to as "miniroot" where
> sproc threads were either not available, or at least not used
> in xfsdump. Throughout xfsdump there's a "miniroot" variable
> which indicates whether or not thread support is enabled. On
> Linux this variable has always been false in order to disable
> support for multiple streams.
>
> Now that the threading infracstructure has been converted over
> to pthreads, this patch removes the "miniroot" variable and
> enables the option of using multiple streams.
>
> Note that another feature in xfsdump, using a ring buffer for
> I/O to tapes, also depends on thread support. I'm leaving that
> disabled for now until more testing has been done.
>
> Reviewed-by: Alex Elder <aelder@xxxxxxx>
> Signed-off-by: Bill Kendall <wkendall@xxxxxxx>
> Signed-off-by: Christoph Hellwig <hch@xxxxxx>
>
> > (I need to produce multiple dump files in order to migrate some data under space constraints.
> > I was planning to produce the dump files on an ext4 filesystem (since you can shrink that), and
> > restore 1 dump file at a time. After restoring each dump file, I can delete it, shrink the ext4
> > filesystem to reclaim space, and expand the destination XFS filesystem.)
>
> I don't think multiple dump streams does what you want.
>
> When you create multiple dump files with a current xfsdump, you also
> need to supply xfsrestore with all those dump files, too, otherwise
> the dump inventory cannot be validated. IOWs, I don't think you can
> just restore a single dump file from a multi-stream dump as data
> being restored may be spread across multiple dump files...
>
> Cheers,
>
> Dave.��.n��������+%������w��{.n�����{����� jg��� �����ݢj����G���� ���j:+v���w�m������w�������h�����٥
