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

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

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 <[email protected]>
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.

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
[email protected]

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