Message ID | 49281F18.7080404@redhat.com |
---|---|
State | Accepted, archived |
Headers | show |
On Nov 22, 2008 09:02 -0600, Eric Sandeen wrote: > This is for RH bugzilla 471925 - Complete scan of filesystems expanded online > > When we resize online, the primary superblock gets copied to all > the backups, and of course since we're mounted the NEEDS_RECOVERY > flag is set. A subsequent fsck will find the backups have the > NEEDS_RECOVERY flag set while the primary does not, and this > forces a full fsck pass. > > I think this flag can be safely ignored in the flag comparisons. Should we also mask out this flag from the backup superblock copies when they are made, or is there an equal chance that the superblock has NEEDS_RECOVERY and the backups do not? > Signed-off-by: Eric Sandeen <sandeen@redhat.com> > --- > > Index: e2fsprogs/e2fsck/super.c > =================================================================== > --- e2fsprogs.orig/e2fsck/super.c 2008-11-22 07:54:47.000000000 -0600 > +++ e2fsprogs/e2fsck/super.c 2008-11-22 08:59:45.953060973 -0600 > @@ -860,7 +860,8 @@ void check_super_block(e2fsck_t ctx) > * try to discourage it in the future. In particular, for the newer > * ext4 files, especially EXT4_FEATURE_RO_COMPAT_DIR_NLINK and > * EXT3_FEATURE_INCOMPAT_EXTENTS. So some of these may go away in the > - * future. > + * future. EXT3_FEATURE_INCOMPAT_RECOVER may also get set when > + * copying the primary superblock during online resize. > * > * The kernel will set EXT2_FEATURE_COMPAT_EXT_ATTR, but > * unfortunately, we shouldn't ignore it since if it's not set in the > @@ -869,7 +870,8 @@ void check_super_block(e2fsck_t ctx) > */ > #define FEATURE_RO_COMPAT_IGNORE (EXT2_FEATURE_RO_COMPAT_LARGE_FILE| \ > EXT4_FEATURE_RO_COMPAT_DIR_NLINK) > -#define FEATURE_INCOMPAT_IGNORE (EXT3_FEATURE_INCOMPAT_EXTENTS) > +#define FEATURE_INCOMPAT_IGNORE (EXT3_FEATURE_INCOMPAT_EXTENTS| \ > + EXT3_FEATURE_INCOMPAT_RECOVER) > > int check_backup_super_block(e2fsck_t ctx) > { > > -- > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Andreas Dilger wrote: > On Nov 22, 2008 09:02 -0600, Eric Sandeen wrote: >> This is for RH bugzilla 471925 - Complete scan of filesystems expanded online >> >> When we resize online, the primary superblock gets copied to all >> the backups, and of course since we're mounted the NEEDS_RECOVERY >> flag is set. A subsequent fsck will find the backups have the >> NEEDS_RECOVERY flag set while the primary does not, and this >> forces a full fsck pass. >> >> I think this flag can be safely ignored in the flag comparisons. > > Should we also mask out this flag from the backup superblock copies > when they are made, or is there an equal chance that the superblock > has NEEDS_RECOVERY and the backups do not? I think it might be a good idea (to mask at growfs time) for completeness. Is there *ever* any valid reason for a backup superblock to have this flag set? Near as I can tell, online growfs is the only thing that ever sets it, and this "flag match" check is the only thing that ever tests it. -Eric -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Eric Sandeen wrote: > This is for RH bugzilla 471925 - Complete scan of filesystems expanded online > > When we resize online, the primary superblock gets copied to all > the backups, and of course since we're mounted the NEEDS_RECOVERY > flag is set. A subsequent fsck will find the backups have the > NEEDS_RECOVERY flag set while the primary does not, and this > forces a full fsck pass. > > I think this flag can be safely ignored in the flag comparisons. ping on this? Andreas wondered about masking the flag when sb backups are written, but I think that only needs to be done in kernelspace; from reading code & testing offline resize, I don't think userspace needs further changes. -Eric > Signed-off-by: Eric Sandeen <sandeen@redhat.com> > --- > > Index: e2fsprogs/e2fsck/super.c > =================================================================== > --- e2fsprogs.orig/e2fsck/super.c 2008-11-22 07:54:47.000000000 -0600 > +++ e2fsprogs/e2fsck/super.c 2008-11-22 08:59:45.953060973 -0600 > @@ -860,7 +860,8 @@ void check_super_block(e2fsck_t ctx) > * try to discourage it in the future. In particular, for the newer > * ext4 files, especially EXT4_FEATURE_RO_COMPAT_DIR_NLINK and > * EXT3_FEATURE_INCOMPAT_EXTENTS. So some of these may go away in the > - * future. > + * future. EXT3_FEATURE_INCOMPAT_RECOVER may also get set when > + * copying the primary superblock during online resize. > * > * The kernel will set EXT2_FEATURE_COMPAT_EXT_ATTR, but > * unfortunately, we shouldn't ignore it since if it's not set in the > @@ -869,7 +870,8 @@ void check_super_block(e2fsck_t ctx) > */ > #define FEATURE_RO_COMPAT_IGNORE (EXT2_FEATURE_RO_COMPAT_LARGE_FILE| \ > EXT4_FEATURE_RO_COMPAT_DIR_NLINK) > -#define FEATURE_INCOMPAT_IGNORE (EXT3_FEATURE_INCOMPAT_EXTENTS) > +#define FEATURE_INCOMPAT_IGNORE (EXT3_FEATURE_INCOMPAT_EXTENTS| \ > + EXT3_FEATURE_INCOMPAT_RECOVER) > > int check_backup_super_block(e2fsck_t ctx) > { > > -- > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Sat, Nov 22, 2008 at 09:02:48AM -0600, Eric Sandeen wrote:
> This is for RH bugzilla 471925 - Complete scan of filesystems expanded online
Applied to the maint branch.
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Index: e2fsprogs/e2fsck/super.c =================================================================== --- e2fsprogs.orig/e2fsck/super.c 2008-11-22 07:54:47.000000000 -0600 +++ e2fsprogs/e2fsck/super.c 2008-11-22 08:59:45.953060973 -0600 @@ -860,7 +860,8 @@ void check_super_block(e2fsck_t ctx) * try to discourage it in the future. In particular, for the newer * ext4 files, especially EXT4_FEATURE_RO_COMPAT_DIR_NLINK and * EXT3_FEATURE_INCOMPAT_EXTENTS. So some of these may go away in the - * future. + * future. EXT3_FEATURE_INCOMPAT_RECOVER may also get set when + * copying the primary superblock during online resize. * * The kernel will set EXT2_FEATURE_COMPAT_EXT_ATTR, but * unfortunately, we shouldn't ignore it since if it's not set in the @@ -869,7 +870,8 @@ void check_super_block(e2fsck_t ctx) */ #define FEATURE_RO_COMPAT_IGNORE (EXT2_FEATURE_RO_COMPAT_LARGE_FILE| \ EXT4_FEATURE_RO_COMPAT_DIR_NLINK) -#define FEATURE_INCOMPAT_IGNORE (EXT3_FEATURE_INCOMPAT_EXTENTS) +#define FEATURE_INCOMPAT_IGNORE (EXT3_FEATURE_INCOMPAT_EXTENTS| \ + EXT3_FEATURE_INCOMPAT_RECOVER) int check_backup_super_block(e2fsck_t ctx) {
This is for RH bugzilla 471925 - Complete scan of filesystems expanded online When we resize online, the primary superblock gets copied to all the backups, and of course since we're mounted the NEEDS_RECOVERY flag is set. A subsequent fsck will find the backups have the NEEDS_RECOVERY flag set while the primary does not, and this forces a full fsck pass. I think this flag can be safely ignored in the flag comparisons. Signed-off-by: Eric Sandeen <sandeen@redhat.com> --- -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html