Bug 1616389

Summary: fsck.gfs2 should honour the filesystem format
Product: Red Hat Enterprise Linux 7 Reporter: Andreas Gruenbacher <agruenba>
Component: gfs2-utilsAssignee: Andrew Price <anprice>
Status: CLOSED ERRATA QA Contact: cluster-qe <cluster-qe>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.6CC: cluster-maint, gfs2-maint, jpayne, rhandlin
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: gfs2-utils-3.1.10-9.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1622050 (view as bug list) Environment:
Last Closed: 2018-10-30 11:37:31 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1622050    
Attachments:
Description Flags
Proposed patch (RHEL7 version) none

Description Andreas Gruenbacher 2018-08-15 18:57:00 UTC
The format of a gfs2 filesystem (sb_fs_format) is defined as GFS2_FORMAT_FS, value 1801.  We are planning to introduce a new filesystem format in RHEL8 for introducing features which are not backwards compatible.

Right now, the kernel will refuse to mount filesystems with a sb_fs_format other than 1801.  However, fsck.gfs2 ignores sb_fs_format, and will happily "repair" filesystems that have a different format.  (It won't reset sb_fs_format to 1801, either.)

So once as we introduce a new format, current versions of fsck.gfs2 will destroy such filesystems.  To prevent that to some degree, we should fix fsck.gfs2 in RHEL7: that way, at least updating from an up-to-date version of RHEL7 to RHEL8 will be safe.

Steps to Reproduce:
1. mkfs.gfs2 -O -p lock_nolock /dev/scratch
2. gfs2_edit -p sb field sb_fs_format 1802 /dev/scratch
3. mount /dev/scratch /mnt/scratch  # this will fail
4. fsck.gfs2 /dev/scratch  # this will succeed, but it should fail

Comment 1 Andrew Price 2018-08-16 11:10:20 UTC
What behaviour do we want when fsck.gfs2 encounters sb_fs_format == 1802? Options:

- Report that the fs format is unsupported and exit non-zero
- Reset the field to 1801, continue checking
- Assume the superblock is corrupted as it's an unknown format, repair

Comment 2 Andreas Gruenbacher 2018-08-16 13:48:40 UTC
Report that the fs format is unsupported and exit non-zero.  We really want to avoid destroying the new format.

Perhaps we want to mention that the fs format can be forced back to 1801 with:
  gfs2_edit -p sb field sb_fs_format 1801 /dev/scratch

Comment 3 Andrew Price 2018-08-17 12:18:59 UTC
Created attachment 1476607 [details]
Proposed patch (RHEL7 version)

commit f91cd7bfb37c6e2dbe120b131f1292746cd94cba
Author: Andrew Price <anprice>
Date:   Fri Aug 17 12:49:24 2018 +0100

    fsck.gfs2: Don't check fs formats we don't recognise
    
    Currently fsck.gfs2 will ignore sb_fs_format but in order to support
    future formats we need to make sure it doesn't try to check filesystems
    with formats we don't recognise yet.
    
    Tests included.

Comment 6 Justin Payne 2018-09-14 15:48:30 UTC
[root@host-135 ~]# rpm -q gfs2-utils
gfs2-utils-3.1.10-9.el7.x86_64
[root@host-135 ~]# mkfs.gfs2 -O -p lock_nolock /dev/sda1
This will destroy any data on /dev/sda1
Discarding device contents (may take a while on large devices): Done
Adding journals: Done 
Building resource groups: Done     
Creating quota file: Done
Writing superblock and syncing: Done
Device:                    /dev/sda1
Block size:                4096
Device size:               200.00 GB (52428790 blocks)
Filesystem size:           200.00 GB (52428788 blocks)
Journals:                  1
Journal size:              128MB
Resource groups:           801
Locking protocol:          "lock_nolock"
Lock table:                ""
UUID:                      9888eefb-db41-411a-ad88-44e730e83aeb
[root@host-135 ~]# gfs2_edit -p sb field sb_fs_format 1802 /dev/sda1
1802
[root@host-135 ~]# mount /dev/sda1 /mnt/test
mount: /dev/sda1 is write-protected, mounting read-only
[346163.785382] GFS2: fsid=: Unknown on-disk format, unable to mount
[346163.786958] GFS2: gfs2 mount does not exist
mount: wrong fs type, bad option, bad superblock on /dev/sda1,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.
[root@host-135 ~]# fsck.gfs2 /dev/sda1
Initializing fsck
Unsupported gfs2 format found: 1802
A newer fsck.gfs2 is required to check this file system.

Comment 8 errata-xmlrpc 2018-10-30 11:37:31 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:3272