#1579 Issue closed: Some options of XFS filesystem might be evaluated as illegal when recovering XFS >= 4.7.0

Labels: bug, fixed / solved / done

gozora opened issue at 2017-11-16 15:54:

Relax-and-Recover (ReaR) Issue Template

  • rear version (/usr/sbin/rear -V):ReaR >= 2.1
  • OS version (cat /etc/rear/os.conf or lsb_release -a): ANY
  • rear configuration files (cat /etc/rear/site.conf or cat /etc/rear/local.conf): N/A
  • Are you using legacy BIOS or UEFI boot? ANY
  • Brief description of the issue:
    When restoring XFS (>=4.7.0) filesystems during rear recover, mkfs.xfs returns (or similar):
Illegal value 0 for -l sunit option. value is too small

jsmeix commented at 2017-11-17 09:44:

@gozora regarding your
https://github.com/rear/rear/issues/1575#issuecomment-344915473

Probably there is no "ultimate automated solution" in ReaR
for such cases so that all what ReaR could do in an
automated way is some "best effort guesswork".

I think in such cases ReaR should report to the user
about its "best effort guesswork" changes e.g. via
LogPrint (that output is only visible in verbose mode)
or with LogPrintError for output that needs to be shown
to the user in any case. This function name indicates that
output that needs to be shown to the user in any case is
(primarily) intended in case of (possible) errors e.g.:

# Make the user aware when existing mkfs.xfs options are removed:
LogPrintError "Probably non-working mkfs.xfs option foo=bar removed"

gozora commented at 2017-11-19 10:52:

I've approached XFS upstream with this topic.
So far I've got recommendation to use xfs_copy, which I really can't imagine to be used with BACKUP=NETFS ...
I'll wait how and if the discussion will continue, maybe there will be some light at the end of the tunnel ;-).

V.

jsmeix commented at 2017-11-20 09:34:

@gozora
do you mean the front light of the train at the end of the tunnel ?
;-)

jsmeix commented at 2017-11-21 12:11:

@gozora
as far as I understand "man xfs_copy" it seems this could be
more appropriate for the BLOCKCLONE backup method ?

In a similar way 'btrfs send' and 'btrfs receive' could be also
appropriate for the BLOCKCLONE backup method.

All those filesystem-specific "whole-filesystem-cloning" tools
are inappropriate for the "normal" file-based backup methods
in ReaR like 'tar' or the usual third party backup tools.

gozora commented at 2017-11-21 12:21:

@jsmeix

as far as I understand "man xfs_copy" it seems this could be
more appropriate for the BLOCKCLONE backup method ?

Exactly xfs_copy does block level copy so if you have 1GB partition you get 1GB backup (doesn't matter how filled), so yes this is much more appropriate for BLOCKCLONE ...

V.

jsmeix commented at 2017-11-21 12:30:

According to my "man xfs_copy" (for xfsprogs-4.3.0)

The length of the resulting file is equal to the size
of the source filesystem. However, if the file is created
on an XFS filesystem, the file consumes roughly the
amount of space actually used in the source filesystem
by the filesystem and the XFS log. The space saving is
because xfs_copy seeks over free blocks instead of
copying them and the XFS filesystem supports
sparse files efficiently.

it seems there could be space saving for the resulting file
on any filesystem that supports sparse files efficiently ?

gozora commented at 2017-11-28 17:36:

I've found nothing really interesting from XFS upstream :-/
As I was studying XFS a bit last week, I think that best solution for this problem to omit -l sunit when equal 0. (https://github.com/rear/rear/pull/1603)

Btw. If one uses external XFS log, ReaR will ignore this fact during recovery and creates log as internal.
I'll try to fix this in upcoming days (but I'll certainly not make it until ReaR 2.3).

V.

jsmeix commented at 2017-11-29 11:38:

With https://github.com/rear/rear/pull/1603 merged
I consider this issue here to be fixed.

@gozora
many thanks for all your work to fix and enhance
the (complicated) XFS support in ReaR!

gozora commented at 2017-11-29 12:12:

Anytime ;-)

[Export of Github issue for rear/rear.]