#1213 Issue closed: XFS mount failed with attributes sunit=128,swidth=86016 after updating RHEL 7.2 to 7.3¶
Labels: bug, fixed / solved / done
gdha opened issue at 2017-03-01 14:24:¶
- rear version (/usr/sbin/rear -V): 2.00
- OS version (cat /etc/rear/os.conf or lsb_release -a): RHEL 7.3
- rear configuration files (cat /etc/rear/site.conf or cat /etc/rear/local.conf):
- Are you using legacy BIOS or UEFI boot? BIOS
- Brief description of the issue:
When I restore an server with redhat 7.3 I will get the following error.
I edited then thediskrestore.shand removed or set the two attributes =0 from all mount commands.
Run the restore script with “5) Continue restore script”, and the restore worked fine.
sunit=128,swidth=86016
sunit=0,swidth=0
The original FS had those attributes set.
/dev/mapper/h50l270vg00-root / xfs rw,relatime,attr2,inode64,logbsize=64k,sunit=128,swidth=86016,noquota 0 0
After rear created the filesystem, those attributes are 0. This shown down under Rear recreate Filesystem
If rear tries to mount the filesystem with sunit=128,swidth=86016, it
get the error.
I guess rear tries to mount the filesystem with the original attributes. If this attributes are newly set to 0 the mount with the original attributes does not work.
But I don’t know, why our filesystemes has set those attributes to this values. The system are building automatically by redhat satellite.
ERROR Message:
+++ Print 'Mounting filesystem /'
+++ test 1
+++ echo -e 'Mounting filesystem /'
+++ mkdir -p /mnt/local/
+++ mount -o rw,relatime,attr2,inode64,logbsize=64k,sunit=128,swidth=86016,noquota /dev/mapper/h50l270vg00-root /mnt/local/
mount: wrong fs type, bad option, bad superblock on /dev/mapper/h50l270vg00-root,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so.
2017-02-28 11:20:53 An error occurred during layout recreation.
Mount Attributes before restore with rear:
/dev/mapper/h50l270vg00-root / xfs rw,relatime,attr2,inode64,logbsize=64k,sunit=128,swidth=86016,noquota 0 0
/dev/mapper/mpatha1 /boot xfs rw,relatime,attr2,inode64,logbsize=64k,sunit=128,swidth=86016,noquota 0 0
/dev/mapper/h50l270vg00-vlog /var/log xfs rw,relatime,attr2,inode64,logbsize=64k,sunit=128,swidth=86016,noquota 0 0
/dev/mapper/h50l270vg00-uloc /usr/local xfs rw,relatime,attr2,inode64,logbsize=64k,sunit=128,swidth=86016,noquota 0 0
/dev/mapper/h50l270vg00-home /home xfs rw,relatime,attr2,inode64,logbsize=64k,sunit=128,swidth=86016,noquota 0 0
/dev/mapper/h50l270vg00-vlsu /var/log/suva xfs rw,relatime,attr2,inode64,logbsize=64k,sunit=128,swidth=86016,noquota 0 0
/dev/mapper/h50l270vg00-alib /app/lib xfs rw,relatime,attr2,inode64,logbsize=64k,sunit=128,swidth=86016,noquota 0 0
Rear recreate command Filesystem
+++ mkfs.xfs -f -m uuid=a7371b95-f96f-4e4e-b4dd-cc2318368198 /dev/mapper/h50l270vg00-alib
meta-data=/dev/mapper/h50l270vg00-alib isize=512 agcount=8, agsize=163840 blks
= sectsz=512 attr=2, projid32bit=1
= crc=1 finobt=0, sparse=0
data = bsize=4096 blocks=1310720, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=1
log =internal log bsize=4096 blocks=2560, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
gdha commented at 2017-03-01 16:23:¶
Let’s say we have an redhat 7.2 server.
If you create an xfs filesystem, on this version, all filesystems are created with this two options. (Maybe on other disk types other options)
sunit=16 swidth=10752 blks
On this level we can restore with rear without problems. All file systems are recreated with this options and mounted while the restore with this option. This seems to be the default for xfs.
Now we migrate this server to *redhat release 7.3*.
All existing file systems have still this options set.
All newly created file system has this option set to 0. I guess the
default has changed.
Now we restore with rear. The rear creates all file systems with the new
iso (redhat 7.3).
All File systems are created with this options =0, because it’s the new
default.
Rear tries now to mount the newly created file systems with the original
options.
I try now to build a server redhat 7.3 directly from source. If the pxe kernel is on release 7.3, all file systems should have the option set to 0.
Redhat 7.2¶
Red Hat Enterprise Linux Server release 7.2 (Maipo) 3.10.0-327.36.1.el7.x86_64
# rpm -qa | grep xfs
xfsprogs-3.2.2-2.el7.x86_64
xfsdump-3.1.4-1.el7.x86_64
Redhat 7.3¶
Red Hat Enterprise Linux Server release 7.3 (Maipo) 3.10.0-514.6.1.el7.x86_64
# rpm -qa | grep xfs
xfsprogs-4.5.0-9.el7_3.x86_64
xfsdump-3.1.4-1.el7.x86_64
Create new file system on version 7.3¶
# mkfs.xfs /dev/`uname -n`vg00/wrat
meta-data=/dev/h50l270vg00/wrat isize=512 agcount=8, agsize=32000 blks
= sectsz=512 attr=2, projid32bit=1
= crc=1 finobt=0, sparse=0
data = bsize=4096 blocks=256000, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=1
log =internal log bsize=4096 blocks=855, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
Existing option for migrated Server¶
# xfs_info /app/lib
meta-data=/dev/mapper/h50l270vg00-alib isize=256 agcount=8, agsize=35200 blks
= sectsz=512 attr=2, projid32bit=1
= crc=0 finobt=0 spinodes=0
data = bsize=4096 blocks=281600, imaxpct=25
= sunit=16 swidth=10752 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=0
log =internal bsize=4096 blocks=2560, version=2
= sectsz=512 sunit=16 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
gdha commented at 2017-03-01 16:23:¶
Issue #1174 might be related?
gozora commented at 2017-03-01 17:09:¶
Hello @gdha
Yes and it is related to #1208 as well.
My
https://github.com/rear/rear/issues/1208#issuecomment-282854316
describes same behavior but with ftype parameter.
Looks like XFS does not forgive! :-)
I was thinking of calling xfs_info for every single XFS filesystem
during rear mkbackup, store is somewhere and using it during
mkfs.xfs ...
@gozora The problem might be across updates of xfsprogs that default
values change. Therefore, during recovery the default values might be
different then the ones captured in the disklayout.conf file, which is
the case in this issue.
gdha commented at 2017-03-06 07:36:¶
The fs line in disklayout.conf file looks like for (when running
rear savelaout):
- RHEL 7.2 (on a SAN attached disk) with xfsprogs-3.2.2-2.el7.x86_64:
fs /dev/mapper/h50l270vg00-home /home xfs uuid=27ae5138-014a-458e-8df2-66fe7edb1e1c label= options=rw,relatime,attr2,inode64,logbsize=64k,sunit=128,swidth=86016,noquota
- RHEL 7.2 upgraded to RHEL 7.3 with xfsprogs-3.2.2-2.el7.x86_64
and then xfsprogs-4.5.0-9.el7_3.x86_64 - afterwards the
mountcommand bails out (see below):
fs /dev/mapper/h50l270vg00-home /home xfs uuid=27ae5138-014a-458e-8df2-66fe7edb1e1c label= options=rw,relatime,attr2,inode64,logbsize=64k,sunit=128,swidth=86016,noquota
- RHEL 7.3 (on a SAN attached disk) with xfsprogs-4.5.0-9.el7_3.x86_64:
fs /dev/mapper/h50l270vg00-home /home xfs uuid=574090d7-be7f-4f54-9243-0612dfb8e048 label= options=rw,relatime,attr2,inode64,noquota
Please note that a fresh installed RHEL 7.3 lacks the parameters
sunit=128,swidth=86016 on a direct attached SAN device.
According
http://xfs.org/index.php/XFS_FAQ#Q:_How_to_calculate_the_correct_sunit.2Cswidth_values_for_optimal_performance
these 2 parameters are meant for RAID performance optimization. Another
article
http://linuxsnippets.net/en/snippet/xfs-how-calculate-correct-sunitswidth-values-optimal-performance
about the same.
-
[ ] The default behaviour with xfsprogs-3.2.2-2 changed when using
mkfs.xfson a direct attached SAN device, especially for the parameterssunit,swidthandcrc -
[ ] Be aware ReaR fails when trying to mount during recovery from an updated RHEL 7.2 to 7.3:
mount -o rw,relatime,attr2,inode64,logbsize=64k,sunit=128,swidth=86016,noquota /dev/mapper/h50l270vg00-root /
and the correct command should be (as the mkfs re-created the file
system with the defaults sunit=0,swidth=0):
mount -o rw,relatime,attr2,inode64,noquota /dev/mapper/h50l270vg00-root /
- [ ] perhaps we need to cross check the values in
disklayout.conffile with the ones returned byxfs_infobefore mounting it in recovery mode? @gozora @jsmeix any thoughts?
Also the/etc/fstabfile may need to be changed.
gozora commented at 2017-03-07 16:01:¶
Hello @gdha,
I was working on this topic a bit.
For me only reasonable and safe way is to parse/save xfs_info data
during rear mkbackup/mkrescue and use this data for filesystem
re-creation during rear recover. Once we have filesystem created with
correct options mount will just work.
If I should host "Least friendly parse output" contest xfs_info would
be winner. (some interesting
reading).
I'll try to find some way how to process these data and transform them
to mkfs.xfs friendly syntax.
V.
gdha commented at 2017-03-08 16:50:¶
@gozora I did some tests by trying to re-use the values found in
options of the fs line in disklayout.conf file. The bottom-line
is not that simple, and what we use to re-create a XFS file systems in
recover mode (the defaults, e.g.
mkfs.xfs -f /dev/mapper/h50l270vg00-root) is most likely the desired
state we want.
[root@centos7-kvm ~]# mkfs.xfs -f /dev/sda1
meta-data=/dev/sda1 isize=256 agcount=4, agsize=52352 blks
= sectsz=512 attr=2, projid32bit=1
= crc=0 finobt=0
data = bsize=4096 blocks=209408, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=0
log =internal log bsize=4096 blocks=853, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
[root@centos7-kvm ~]# mount /dev/sda1 /mnt
[root@centos7-kvm ~]# xfs_info /mnt
meta-data=/dev/sda1 isize=256 agcount=4, agsize=52352 blks
= sectsz=512 attr=2, projid32bit=1
= crc=0 finobt=0
data = bsize=4096 blocks=209408, imaxpct=25
= sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=0
log =internal bsize=4096 blocks=853, version=2
= sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
## options=rw,relatime,attr2,inode64,logbsize=64k,sunit=128,swidth=86016,noquota
[root@centos7-kvm ~]# mkfs.xfs -f -l size=64k -d sunit=128 -d swidth=86016 /dev/sda1
log size 16 blocks too small, minimum size is 768 blocks
Usage: mkfs.xfs
/* blocksize */ [-b log=n|size=num]
/* metadata */ [-m crc=0|1,finobt=0|1]
/* data subvol */ [-d agcount=n,agsize=n,file,name=xxx,size=num,
(sunit=value,swidth=value|su=num,sw=num|noalign),
sectlog=n|sectsize=num
/* force overwrite */ [-f]
/* inode size */ [-i log=n|perblock=n|size=num,maxpct=n,attr=0|1|2,
projid32bit=0|1]
/* no discard */ [-K]
/* log subvol */ [-l agnum=n,internal,size=num,logdev=xxx,version=n
sunit=value|su=num,sectlog=n|sectsize=num,
lazy-count=0|1]
/* label */ [-L label (maximum 12 characters)]
/* naming */ [-n log=n|size=num,version=2|ci,ftype=0|1]
/* no-op info only */ [-N]
/* prototype file */ [-p fname]
/* quiet */ [-q]
/* realtime subvol */ [-r extsize=num,size=num,rtdev=xxx]
/* sectorsize */ [-s log=n|size=num]
/* version */ [-V]
devicename
<devicename> is required unless -d name=xxx is given.
<num> is xxx (bytes), xxxs (sectors), xxxb (fs blocks), xxxk (xxx KiB),
xxxm (xxx MiB), xxxg (xxx GiB), xxxt (xxx TiB) or xxxp (xxx PiB).
<value> is xxx (512 byte blocks).
[root@centos7-kvm ~]# mkfs.xfs -f -d sunit=128 -d swidth=86016 /dev/sda1
meta-data=/dev/sda1 isize=256 agcount=8, agsize=26176 blks
= sectsz=512 attr=2, projid32bit=1
= crc=0 finobt=0
data = bsize=4096 blocks=209408, imaxpct=25
= sunit=16 swidth=10752 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=0
log =internal log bsize=4096 blocks=768, version=2
= sectsz=512 sunit=16 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
My conclusions:
-
[ ] save the
/etc/fstabfile during the savelayout work-flow under/var/lib/rear/layout/configdirectory and give it a name likefstab.txtto differentiate from/etc/fstabas we will only use it to find the options for a given file system (if needed of course) -
[ ] if we find defaults in the
fstab.txtfor a fs line we want to re-create then we are save to get rid of any options that might give conflicts, likelogbsize=64k,sunit=128,swidth=86016
gozora commented at 2017-03-08 17:07:¶
Hello @gdha
The bottom-line is not that simple, and what we use to re-create a XFS file systems in recover mode (the defaults, e.g. mkfs.xfs -f /dev/mapper/h50l270vg00-root) is most likely the desired state we want.
I agree that this is not a simple thing to do, but using defaults is not desirable (to my opinion).
Imagine situation where you would create your file system with e.g.
crc=1 (despite it is non default option.) I think that using non
default options is perfectly fine and ReaR should reflect user choice
during rear recover. In upper listed scenario you'd get back system
which have crc=0 hence some applications that were previously
working might start misbehave, or performance problems might be
introduced. (Take
https://github.com/rear/rear/issues/1208
as an example).
Now speaking as sysadmin, I would really not appreciate this much ...
V.
gdha commented at 2017-03-09 07:35:¶
@gozora strictly spoken you are right, however, in practice I noticed
that mkfs.xfs seems to do whatever it pleases with most parameters
given, or by bailing out (and end-user complains), or by modifying the
parameters to whatever XFS thinks best fit. I assume as sysadmin that
gives you a bad feeling as well. For this reason I find it very
uncomfortable to choose between defaults (what we do now) and do the
right thing (and increasing bailing out).
Therefore, I think that using the input from fstab.txt could help us
to decide what was defined before? OTOH, you can tune XFS in other ways
too and that complicate things further. Pff need some time to decide.
@jsmeix Can you assist us in making a decision? :-)
jsmeix commented at 2017-03-09 09:09:¶
A generic proposal from my point of view:
I assume we can agree that in practice it is impossible
(with reasonable effort) that ReaR always recreates a
filesystem exactly as it was on the original system. cf.
https://github.com/rear/rear/issues/1208#issuecomment-282991951
Furthermore my personal opinion is that currently ReaR
tries too much to do things right in a silently working
automated way, cf.
https://github.com/rear/rear/pull/1204#issuecomment-282252947
Therefore I would like to suggest that first and foremost
configuration variables are implemented where the user can
(if needed) specify special filesystem setup parameters, cf.
the new USB_DEVICE_FILESYSTEM_PARAMS variable, see
https://github.com/rear/rear/pull/1217/files
This way the user has at least some manual means for now
to enforce that "rear recover" results exactly what he needs.
Afterwards step by step ReaR can be further enhanced to
autodetect more and more filesystem settings so that then
step by step ReaR can recreate a filesystem more and more
as is was before.
Because during "rear recover" several filesystems are recreated
(also several filesystems of same type) I have currently no real
good idea how configuration variables for filesystem setup
parameters could be best implemented. I think those variables
have to be arrays but currently I have no real good idea
how to generically specify which parameters should belong
to which particular filesystem. Perhaps using the device node
of the filesystem (e.g. /dev/sda1 ) to match an 'fs' entry
in disklayout.conf is a useful way?
gozora commented at 2017-03-09 15:05:¶
Hello @gdha
I noticed that mkfs.xfs seems to do whatever it pleases with most parameters given, or by bailing out (and end-user complains), or by modifying the parameters to whatever XFS thinks best fit.
Yes, I've noticed this as well, sunit, swidth are such parameters where you need to include some math to set them correctly. There is also a group of parameters that are derived or mutually exclusive ....
Therefore, I think that using the input from fstab.txt could help us to decide what was defined before? OTOH, you can tune XFS in other ways too and that complicate things further. Pff need some time to decide.
This is another nightmare, because mount options would not tell you about how e.g. crc, ftype are setup ...
I'm trying to find out reasonable (both readable and easy to maintain) sollution that could help here. So far I've failed 3 times already, but I keep trying. At the end it is interesting challenge for me ...
@jsmeix
Furthermore my personal opinion is that currently ReaR
tries too much to do things right in a silently working
automated way, cf.
I take the risk that you will refuse merging PR (if I ever succeed to write it :-)), and I'll fully understand that! But who knows, maybe you will like it at the end ;-).
V.
gozora commented at 2017-03-09 20:23:¶
Hello @gdha, @jsmeix,
I've created first prototype of
code
that could help to solve this problem.
I'd like to know your opinion on this idea in general.
If you would like to test it:
# xfs_info <xfs_filesystem_to_examine> | ./xfs_parse-0.1.0.sh
which outputs something like:
mkfs.xfs -f -i size=512 -d agcount=4 -s size=1024 -i attr=2 -i projid32bit=1 -m crc=1 -m finobt=0 -b size=2048 -i maxpct=50 -d sunit=0 -d swidth=0 <device>
V.
jsmeix commented at 2017-03-10 09:19:¶
@gozora
regarding your
https://github.com/rear/rear/issues/1213#issuecomment-285376306
"I take the risk that you will refuse merging PR":
Don't worry:
I will not refuse to merge useful additional automatisms.
But I think you may have misunderstood what I mean.
I am not against automatisms.
I am for automatisms as default or fallback functionality.
I am against automatisms that remove the final control from the user
(which I called "do things in a silently working automated way").
Have a look at
https://github.com/rear/rear/pull/1212
how I have documented UEFI_BOOTLOADER
in default.conf (so that it is no longer "silently working") and
how I have implemented UEFI_BOOTLOADER support in
https://raw.githubusercontent.com/rear/rear/master/usr/share/rear/rescue/default/850_save_sysfs_uefi_vars.sh
therein in particular (excerpts):
When the user has specified UEFI_BOOTLOADER in /etc/rear/local.conf use it ... fall back step by step to more and more complicated autodetection methods until a usable UEFI bootloader file is found or error out if nothing is found ... what the user has specified must have precedence over automatisms
This way the user still has the final control because when he
specifies UEFI_BOOTLOADER this is used (and nothing else)
but when the user does not make such a decision
ReaR does various automatisms to "get things right"
and if that fails ReaR errors out at that current place
with a meaningful error message, cf.
https://github.com/rear/rear/issues/1233
jsmeix commented at 2017-03-10 09:31:¶
@gdha @gozora FYI:
currently I do not have much time for ReaR issues
because currently I have to work on other areas
which is currently mainly printing related stuff, cf.
https://en.opensuse.org/User:Jsmeix
gdha commented at 2017-03-10 14:34:¶
@gozora I think you are on the right track - looks promising so far.
gozora commented at 2017-03-23 10:10:¶
I have first version that can create XFS fielsystem reasonably well, now I'll try to integrate it into ReaR without creating havoc ...
V
jsmeix commented at 2017-03-23 12:00:¶
Wow!
https://github.com/gozora/xfs_parse/blob/master/xfs_parse.sh
looks daunting.
gozora commented at 2017-03-23 20:31:¶
Hello @gdha, hello @jsmeix
My first idea would be to trigger save of XFS related options using
230_filesystem_layout.sh
into $VAR_DIR/layout/config/.
This configs would be later transposed by
xfs_parse.sh
to mkfs.xfs -f ... command used in diskrestore.sh
What do you think?
V.
jsmeix commented at 2017-03-24 09:20:¶
@gozora
I think during "rear mkbackup/mkrescue" saving XFS specific things
into a file in $VAR_DIR/layout/ and use that during "rear recover"
is "the one and only" (TM) right way.
On only wonder if $VAR_DIR/layout/config/ is right
or perhaps if $VAR_DIR/layout/xfs/ could be better?
In the end this does not really matter.
Use whatever file in $VAR_DIR/layout/ you like most.
I also wonder if for XFS specific things a separated new script
layout/save/GNU/Linux/232_xfs_filesystem_settings.sh
would be better?
gozora commented at 2017-03-24 09:50:¶
Hello @jsmeix
On only wonder if $VAR_DIR/layout/config/ is right
or perhaps if $VAR_DIR/layout/xfs/ could be better?
In the end this does not really matter.
Use whatever file in $VAR_DIR/layout/ you like most.
Fine with that, for me it doesn't really matter where we will store xfs properties files.
I also wonder if for XFS specific things a separated new script
layout/save/GNU/Linux/232_xfs_filesystem_settings.sh
would be better?
I've decided to use 230_filesystem_layout.sh because it already contains code that handles some XFS specific tasks:
(xfs)
uuid=$(xfs_admin -u $device | cut -d'=' -f 2 | tr -d " ")
label=$(xfs_admin -l $device | cut -d'"' -f 2)
echo -n " uuid=$uuid label=$label "
xfs_info $device > $VAR_DIR/layout/config/$(basename ${device}.rear_xfs)
;;
Creating separate file for saving XFS options will in my opinion create duplicate code with same functionality we already have.
But if you think it will be easier to read, I have no problem adapting it.
V.
jsmeix commented at 2017-03-24 10:06:¶
@gozora
I fully agree that code for one same functionality
(here XFS options) must be at one same place, cf.
https://github.com/rear/rear/issues/1229#issuecomment-286998459
In general:
Because you implement and maintain it,
you make the decisions what is best.
What I do are only some side notes
from an outsider's point of view.
gozora commented at 2017-03-26 14:02:¶
Hello @gdha, hello @jsmeix,
I have first working code for parsing XFS options ready. I'll do pull request once I've done broader testing of this code. (so far only Centos 7.2 was tested).
I've used following test scenario, which old ReaR code was not able to handle:
-
XFS logical volume created with following parameters:
mkfs.xfs -f -i size=1024 -d agcount=4 -s size=512 -i attr=2 -i projid32bit=1 -m crc=1 -m finobt=0 -b size=4096 -i maxpct=25 -d sunit=512 -d swidth=1024 -l version=2 -l sunit=0 -l lazy-count=1 -n size=4096 -n version=ci -r extsize=4096 -n ftype=1 /dev/mapper/vg00-lv_xfs -
/etc/fstab entry:
/dev/mapper/vg00-lv_xfs /data xfs sunit=512,swidth=1024,attr2 0 0
@gdha If you know someone struggling with this XFS problem and willing to do some testing, https://github.com/gozora/rear/tree/xfs_parse is branch to clone.
Thanks
V.
gozora commented at 2017-03-26 20:02:¶
Tests on SLES12 SP1 passed!
Only troublemaker occurred was problem with mounting of XFS partition.
Mount failed with error: mount: Structure needs cleaning
This was caused by code in 130_include_filesystem_code.sh:
xfs_admin -U $uuid $device >&2
Fortunately it was easy to fix with xfs_repair
Next week I'll continue with tests on Debian and its derivatives (Ubuntu and Mate) and SLES11.
V.
gdha commented at 2017-03-28 14:12:¶
@gozora The modified in script 230_filesystem_layout.sh works fine:
$ cat ./rear/var/lib/rear/layout/xfs/vgswap-lvxfs.xfs
meta-data=/dev/mapper/vgswap-lvxfs isize=256 agcount=8, agsize=25598 blks
= sectsz=512 attr=2, projid32bit=1
= crc=0 finobt=0
data = bsize=4096 blocks=204784, imaxpct=25
= sunit=2 swidth=64 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=0
log =internal bsize=4096 blocks=512, version=2
= sectsz=512 sunit=2 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0
I would rename script usr/share/rear/lib/xfs-functions.sh into
usr/share/rear/lib/filesystems-functions.sh in case we need to add
new functions for new to discover file systems.
In script
usr/share/rear/layout/prepare/GNU/Linux/130_include_filesystem_code.sh
I have one doubt with line
echo " mkfs.xfs -f $xfs_opts $device >&2" - what if the values
create by the mkfs.xfs code are slightly different then what we
give?
It could be that the mount command would still fail, because the mount
options registered in the mount options variable of the fs line in the
disklayout.conf file would differ from the ones we created above by
the mkfs.xfs command.
To be fair I did not come that far in my tests.
gozora commented at 2017-03-28 14:50:¶
Hello @gdha,
I would rename script usr/share/rear/lib/xfs-functions.sh into usr/share/rear/lib/filesystems-functions.sh in case we need to add new functions for new to discover file systems.
Sure will do.
In script usr/share/rear/layout/prepare/GNU/Linux/130_include_filesystem_code.sh I have one doubt with line echo " mkfs.xfs -f $xfs_opts $device >&2" - what if the values create by the mkfs.xfs code are slightly different then what we give?
It could be that the mount command would still fail, because the mount options registered in the mount options variable of the fs line in the disklayout.conf file would differ from the ones we created above by the mkfs.xfs command.
There should be no problem with this. 230_filesystem_layout.sh first
dumps file system parameters during rear mkbackup/mkrescue and ReaR
later stores mount parameters for each XFS filesystem. Meaning that if
you had mounted XFS file system during rear mkbackup/mkrescue you have
a quite good chance that rescue system will mount it without problems as
well.
If you have some real life example when we could have failure with
mounting, just let me know and I'll test it.
I'm still testing different XFS versions and looking for possible
problems, but so far it looks quite well.
For an update, yesterday I've done tests on Ubuntu Mate 16.4 with quite
new version of XFS and it just worked.
Today I'm continuing with Debian Jessie ...
V.
jsmeix commented at 2017-03-31 07:26:¶
With
https://github.com/rear/rear/pull/1276
merged
I think this issue should be fixed.
If not it can be reopened.
For each other separated XFS related problem
a separated new GitHub issue should be submitted.
jsmeix commented at 2017-03-31 07:28:¶
@gozora
many thanks for your brave fighting against XFS monsters!
;-)
gozora commented at 2017-03-31 08:23:¶
No problem, hope it will do more good than harm ;-).
[Export of Github issue for rear/rear.]