Bug 457964

Summary: Fils system check forced after online resize
Product: [Fedora] Fedora Reporter: Jochen Schmitt <jochen>
Component: e2fsprogsAssignee: Eric Sandeen <esandeen>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: medium    
Version: 9CC: kzak, oliver, tytso
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-12-02 20:18:30 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
fedora patch none

Description Jochen Schmitt 2008-08-05 19:48:32 UTC
Description of problem:

If I'm doing a online resize of a lvm partition, the system will check the resized files system after the next reboot and shows following reason for this action

'primary superblock features different from backup'

Comment 1 Eric Sandeen 2008-08-21 21:05:36 UTC
Sorry for the late reply.  I'll look into this.  Do you know (roughly) which version of e2fsprogs created the filesystem, and which version you used to resize?

Thanks,
-Eric

Comment 2 Theodore Tso 2008-08-21 23:09:25 UTC
This is normal for e2fsprogs 1.41; it forces a fsck if it notices the backup superblocks are different from the primary superblock, to avoid corrupting a valid backup before copying the primary sb to the backup superblocks.   Otherwise, we were losing filesystems where the primary superblock was corrupted.

I can see this could be annoying for very large filesystems that are getting resized.  I suppose we could have resize2fs check to make sure the primary and the backup superblocks are equivalent, then do the resize, and then force a copy to the backup superblocks to avoid the fsck.

Comment 3 Eric Sandeen 2008-08-21 23:26:25 UTC
Created attachment 314764 [details]
fedora patch

Ted, we should probably also print out *which* flags differed.

This is normal, except that FWIW I'm currently still carrying a patch in fedora which continues to ignore a bit more than upstream (I need to make that smarter ...)

Since fedora was setting xattrs, upstream e2fsprogs would cause a full fsck right after install :(

Comment 4 Theodore Tso 2008-08-22 13:04:16 UTC
Well, in this case it isn't a matter of which flags differed, but rather that the *size* of the filesystem is quite different.

As far as the setting xattrs, the upstream mke2fs.conf file sets the xattr compat flag, so the filesystem feature flag should be getting set when the filesystem is freshly created.  So as long as the install media is using e2fsprogs 1.41 with the 1.41 mke2fs.conf file, your patch shouldn't be needed to prevent a full fsck right after install.  (This being a side issue from the original BZ report, though.)

Comment 5 Eric Sandeen 2008-12-02 20:18:30 UTC
Duping to bug 471925 - I think it's the same issue, and there's more information over there (even though it came after this one, sorry!)

*** This bug has been marked as a duplicate of bug 471925 ***