xfsdump: too many -f arguments: maximum is 1 when running in miniroot

xfsdump: too many -f arguments: maximum is 1 when running in miniroot

[Ryan Taylor]

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
xfsdump: usage: xfsdump [ -a (dump DMF dualstate files as offline) ]
                        [ -b <blocksize> ]
                        [ -c <media change alert program>  ]
                        [ -d <dump media file size>  ]
                        [ -e (allow files to be excluded) ]
                        [ -f <destination> ... ]
                        [ -h (help) ]
                        [ -l <level> ]
                        [ -m (force usage of minimal rmt) ]
                        [ -o (overwrite tape) ]
                        [ -p <seconds between progress reports> ]
                        [ -q <use QIC tape settings> ]
                        [ -s <subtree> ... ]
                        [ -t <file> (use file mtime for dump time ]
                        [ -v <verbosity {silent, verbose, trace}> ]
                        [ -z <maximum file size> ]
                        [ -A (don't dump extended file attributes) ]
                        [ -B <base dump session id> ]
                        [ -E (pre-erase media) ]
                        [ -F (don't prompt) ]
                        [ -I (display dump inventory) ]
                        [ -J (inhibit inventory update) ]
                        [ -L <session label> ]
                        [ -M <media label> ... ]
                        [ -O <options file> ]
                        [ -R (resume) ]
                        [ -T (don't timeout dialogs) ]
                        [ -Y <I/O buffer ring length> ]
                        [ - (stdout) ]
                        [ <source (mntpnt|device)> ]
xfsdump: Dump Status: ERROR

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

Why does it think I am running in miniroot? How can this error be avoided?

Thanks,
-rt

-- 
Ryan Taylor
Research Computing Specialist
Research Computing Services, University Systems, University of Victoria

Re: xfsdump: too many -f arguments: maximum is 1 when running in miniroot

[Dave Chinner]

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@sgi.com>
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@sgi.com>
    Signed-off-by: Bill Kendall <wkendall@sgi.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>

> (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.
-- 
Dave Chinner
david@fromorbit.com

Re: xfsdump: too many -f arguments: maximum is 1 when running in miniroot

[Ryan Taylor]

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@sgi.com>
> 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@sgi.com>
>     Signed-off-by: Bill Kendall <wkendall@sgi.com>
>     Signed-off-by: Christoph Hellwig <hch@lst.de>
> 
> > (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.