New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
XFS mount failed with attributes sunit=128,swidth=86016 after updating RHEL 7.2 to 7.3 #1213
Comments
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)
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. Now we restore with rear. The rear creates all file systems with the new iso (redhat 7.3). 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.2Red Hat Enterprise Linux Server release 7.2 (Maipo) 3.10.0-327.36.1.el7.x86_64
Redhat 7.3Red Hat Enterprise Linux Server release 7.3 (Maipo) 3.10.0-514.6.1.el7.x86_64
Create new file system on version 7.3
Existing option for migrated Server
|
Issue #1174 might be related? |
Hello @gdha Looks like XFS does not forgive! :-) I was thinking of calling @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 |
The
Please note that a fresh installed RHEL 7.3 lacks the parameters
and the correct command should be (as the mkfs re-created the file system with the defaults
|
Hello @gdha, I was working on this topic a bit. If I should host "Least friendly parse output" contest V. |
@gozora I did some tests by trying to re-use the values found in
My conclusions:
|
Hello @gdha
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 Now speaking as sysadmin, I would really not appreciate this much ... V. |
@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). |
A generic proposal from my point of view: I assume we can agree that in practice it is impossible Furthermore my personal opinion is that currently ReaR Therefore I would like to suggest that first and foremost This way the user has at least some manual means for now Afterwards step by step ReaR can be further enhanced to Because during "rear recover" several filesystems are recreated |
Hello @gdha
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 ....
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 ...
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. |
I've created first prototype of code that could help to solve this problem. If you would like to test it: which outputs something like: V. |
@gozora Don't worry: But I think you may have misunderstood what I mean. I am not against automatisms. I am against automatisms that remove the final control from the user Have a look at 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 |
@gdha @gozora FYI: |
@gozora I think you are on the right track - looks promising so far. |
I have first version that can create XFS fielsystem reasonably well, now I'll try to integrate it into ReaR without creating havoc ... V |
Wow! |
My first idea would be to trigger save of XFS related options using 230_filesystem_layout.sh into $VAR_DIR/layout/config/. What do you think? V. |
@gozora On only wonder if $VAR_DIR/layout/config/ is right I also wonder if for XFS specific things a separated new script |
Hello @jsmeix
Fine with that, for me it doesn't really matter where we will store xfs properties files.
I've decided to use 230_filesystem_layout.sh because it already contains code that handles some XFS specific tasks:
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. |
@gozora In general: |
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:
@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. |
Tests on SLES12 SP1 passed! Only troublemaker occurred was problem with mounting of XFS partition. Next week I'll continue with tests on Debian and its derivatives (Ubuntu and Mate) and SLES11. V. |
@gozora The modified in script
I would rename script In script |
Hello @gdha,
Sure will do.
There should be no problem with this. I'm still testing different XFS versions and looking for possible problems, but so far it looks quite well. V. |
With #1276 merged For each other separated XFS related problem |
@gozora |
No problem, hope it will do more good than harm ;-). |
When I restore an server with redhat 7.3 I will get the following error.
I edited then the
diskrestore.sh
and 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.
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:
Mount Attributes before restore with rear:
Rear recreate command Filesystem
The text was updated successfully, but these errors were encountered: