#1603 PR merged: Fix for XFS file system recreation code.¶
Labels: bug, fixed / solved / done
gozora opened issue at 2017-11-28 17:29:¶
In xfsprogs >= 4.7 log section sunit=0 is considered invalid.
c.f.
https://github.com/rear/rear/issues/1579
gozora commented at 2017-11-29 11:27:¶
Hello @jsmeix,
i=$((i+1)) and (( i += 1 )) are same a perfectly valid way how to
increment variable. Not sure about overhead on lower levels but outcome
is the same.
I don't remember why I'd choose one or the the other way, but until it creates a problem, I just trust my past me for having a reason.
I wonder if xfs_param_count is perhaps
just ${#xfs_param_iname[@]} ?
This is not part of the pull request, so feel free to update it how ever
you like. It is some time since I've implement this parsing nightmare.
In the near future I'll try to write patch for
https://github.com/rear/rear/issues/1604
(until somebody else writes it) so I'll need to retest whole code.
That could be place for updating comments (and maybe iterators) ;-).
V.
jsmeix commented at 2017-11-29 11:36:¶
@gozora
I am sorry my "FYI" addedum caused confusion.
It was of course not meant that anything in your
currently working code should be changed now
via this pull request shortly before the ReaR 2.3 release.
Again sorry for my useless addedum at this time
and many thanks for your fix!
gozora commented at 2017-11-29 11:47:¶
@jsmeix no need for apologies!
Your comments are not useless!
This fix (neither XFS recreation code) is not perfect, and it will
require a bit more work to recreate XFS file systems correctly. But it
comes from XFS nature, I guess you had similar fun with btrfs ;-)
V.
jsmeix commented at 2017-11-29 12:00:¶
I fear I had and will have "much more fun" with btrfs
because btrfs subvolumes basically behave like filesystems
within a whole btrfs (because subvolumes can be mounted).
This "just breaks" the traditional assumption that one mount point
belongs to one filesystem which is still a basic assumption for
the whole current disk layout code in ReaR.
Therefore since btrfs the whole disk layout code in ReaR
actually needs to be fundamentally overhauled.
I try as good as I can to ignore that skeleton in the closet ;-)
jsmeix commented at 2017-11-29 13:31:¶
Only an addedum FYI regarding
ReaR's disk layout code skeleton in the closet:
Meanwhile I found what I had already written about it, see
https://github.com/rear/rear/issues/497#issuecomment-66448475
and
https://github.com/rear/rear/issues/497#issuecomment-71650367
and the subsequent comment
https://github.com/rear/rear/issues/497#issuecomment-71652667
and finally my currenly latest reasoning
https://github.com/rear/rear/pull/1091#issuecomment-263819775
[Export of Github issue for rear/rear.]