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@xxxxxxxxxx>
> ---
>
> 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@xxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
