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'
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
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.
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 :(
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.)
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 ***