This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 457964 - Fils system check forced after online resize
Fils system check forced after online resize
Status: CLOSED DUPLICATE of bug 471925
Product: Fedora
Classification: Fedora
Component: e2fsprogs (Show other bugs)
9
All Linux
medium Severity medium
: ---
: ---
Assigned To: Eric Sandeen
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-08-05 15:48 EDT by Jochen Schmitt
Modified: 2008-12-02 15:18 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-12-02 15:18:30 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
fedora patch (1.48 KB, patch)
2008-08-21 19:26 EDT, Eric Sandeen
no flags Details | Diff

  None (edit)
Description Jochen Schmitt 2008-08-05 15:48:32 EDT
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 17:05:36 EDT
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 19:09:25 EDT
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 19:26:25 EDT
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 09:04:16 EDT
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 15:18:30 EST
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 ***

Note You need to log in before you can comment on or make changes to this bug.