#2005 PR `merged`: Provide final power to the user for mkfs.xfs options if needed (issue 1998)¶

Labels: enhancement, fixed / solved / done

jsmeix opened issue at 2018-12-14 14:53:¶

Type: Enhancement
Impact: High
Usually this is not needed but if the worst comes to the worst
an easy way to specify mkfs.xfs options it is likely highly appreciated.
Reference to related issue (URL):
https://github.com/rear/rear/issues/1998
How was this pull request tested?
Currently it is not at all tested by me.
Currently it is meant so that @gozora can have a first look, cf.
https://github.com/rear/rear/issues/1998#issuecomment-447325672
Brief description of the changes in this pull request:
Via the new optional global MKFS_XFS_OPTIONS config variable
the user can specify mkfs.xfs options for all mkfs.xfs calls
and/or via optional device specific config variables like
MKFS_XFS_OPTIONS_SDA2
the user can specify mkfs.xfs options only for the mkfs.xfs call
for that dvice (e.g. for /dev/sda2 via MKFS_XFS_OPTIONS_SDA2)
where device specific config variables take precedence over
a global MKFS_XFS_OPTIONS config variable which
takes precedence over the not changed default behaviour
where device specific options for the mkfs.xfs calls are set via
xfs_parse $LAYOUT_XFS_OPT_DIR/$xfs_device_basename.xfs

schlomo commented at 2018-12-16 17:16:¶

Great, I am wondering about the following question: Why not feed the content of the variables into the $LAYOUT_XFS_OPT_DIR/$xfs_device_basename.xfs files and skip the whole logic of sourcing the XFS options from both files and config vars? Won't that make it simpler?

gozora commented at 2018-12-16 17:31:¶

@schlomo
Syntax of $LAYOUT_XFS_OPT_DIR/$xfs_device_basename.xfs and MKFS_XFS_OPTIONS is not compatible.
$LAYOUT_XFS_OPT_DIR/$xfs_device_basename.xfs hold plain output of xfs_info which looks something like:

meta-data=/dev/sda               isize=512    agcount=66, agsize=268435392 blks
         =                       sectsz=4096  attr=2, projid32bit=1
         =                       crc=1        finobt=0 spinodes=0
data     =                       bsize=4096   blocks=17580367872, imaxpct=1
         =                       sunit=64     swidth=576 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal               bsize=4096   blocks=521728, version=2
         =                       sectsz=4096  sunit=1 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0

and need additional parsing by ReaR xfs_parse function.

Where MKFS_XFS_OPTIONS accepts plain options for mkfs.xfs command like -i size=512 -d agcount=4 -s size=512 -i attr=2 -i projid32bit=1 -m crc=1 -m finobt=1 -b size=4096 -i maxpct=25 -d sunit=0 -d swidth=0 -l version=2 -l lazy-count=1 -n size=4096 -n version=2 -r extsize=4096

V.

jsmeix commented at 2018-12-17 10:41:¶

@schlomo
in general regarding your above questions:
Have MIGRATION_MODE in mind.

When XFS filesystems get recreated on same hardware
things "just work" (except the original system is already broken).

But when things do not "just work"
(e.g. because of different replacement hardware
or because the original system is already broken
as in https://github.com/rear/rear/issues/1998)
then we are in MIGRATION_MODE.

My point is that MIGRATION_MODE can be expected by the user
(when he recreates on different replacement hardware)
but MIGRATION_MODE can also happen all of a sudden
when things do not "just work" for whatever reason.

When we are in MIGRATION_MODE and "rear recover" fails
then ReaR should provide means so that the user can
relatively easily recover by some manual intervention.

Currently such manual intervention is often adapting diskrestore.sh
which is not really user-friendly (I consider code hacking within
the recovery system in general not really user-friendly) and
it becomes annoying and error-prone when the user has to receate/migrate
many systems because he would have to manually adapt diskrestore.sh
again and again for each system.

Config variables like MKFS_XFS_OPTIONS and MKFS_XFS_OPTIONS_$device
are meant to make the user's life a bit easier in such cases because with
such config variables he could do things like

# export MKFS_XFS_OPTIONS="generic options"
# export MKFS_XFS_OPTIONS_SDA2="all options for sda2"
# export MKFS_XFS_OPTIONS_SDB3="$MKFS_XFS_OPTIONS additional sdb3 options"
# rear -D recover

jsmeix commented at 2018-12-17 11:04:¶

Regarding it should break during 'mkrescue' and not later in
https://github.com/rear/rear/pull/2005#pullrequestreview-185396888

YES!
I do fully agree.

But current ReaR is far away from that behaviour, cf.
https://github.com/rear/rear/wiki/Developers-Guide

Current ReaR requires to test "rear recover" on already
available replacement hardware and see how things work,
cf. the section "Inappropriate expectations" in
https://en.opensuse.org/SDB:Disaster_Recovery

But sometimes (perhaps even often in practice) "rear recover"
was not sufficiently tested (or the last test was too long ago),
cf. continuous validation in
https://en.opensuse.org/SDB:Disaster_Recovery
so that "rear recover" unexpectedly fails when it is a real disaster recovery
( according to Murphy's Law it only fails when it is a real disaster recovery ;-)
and then the poor user is inside the recovery system where he must
get things back to work...

jsmeix commented at 2018-12-17 16:53:¶

I have tested it and for me with a simple XFS it works o.k.

Now it uses LogPrint to show exceptional info on the user's terminal
and Log when things happen as usual: "no news is good news".

jsmeix commented at 2018-12-18 10:16:¶

If there are no severe objections I would like to merge it today afternoon.
Of course I could further enhance it later if needed.

schlomo commented at 2018-12-18 10:30:¶

👍

[Export of Github issue for rear/rear.]

#2005 PR merged: Provide final power to the user for mkfs.xfs options if needed (issue 1998)¶