On 5/26/15 5:51 PM, Darrick J. Wong wrote: > Apparently xfs_repair running on a v5 filesystem doesn't check the > compat, rocompat, or incompat feature flags for bits that it doesn't > know about, which means that old xfs_repairs can wreak havoc. So, > strengthen the checks to prevent repair from "repairing" anything it > doesn't understand. > > Signed-off-by: Darrick J. Wong <darrick.wong@xxxxxxxxxx> > --- > repair/versions.c | 7 +++++++ > 1 file changed, 7 insertions(+) > > > diff --git a/repair/versions.c b/repair/versions.c > index c1dff72..e60574d 100644 > --- a/repair/versions.c > +++ b/repair/versions.c > @@ -141,6 +141,13 @@ parse_sb_version(xfs_sb_t *sb) > } > } > > + /* Look for V5 feature flags we don't know about */ > + if (XFS_SB_VERSION_NUM(sb) >= XFS_SB_VERSION_5 && > + (xfs_sb_has_ro_compat_feature(sb, XFS_SB_FEAT_RO_COMPAT_UNKNOWN) || > + xfs_sb_has_incompat_feature(sb, XFS_SB_FEAT_INCOMPAT_UNKNOWN) || > + xfs_sb_has_compat_feature(sb, XFS_SB_FEAT_COMPAT_UNKNOWN))) > + issue_warning = 1; > + should this go after the xfs_sb_good_version() check? Seems like it's more of a fine-grained check on features for a given super version, and should come after that check. i.e. if for some reason XFS_SB_VERSION_NUM == 6, the root problem isn't the feature set, it's the superblock version number. And; would it be worth printing out what the features are? I guess we have no good existing mechanism for that, and could really only print hex values... still, might be useful for bug reports... -Eric > if (issue_warning) { > do_warn( > _("This filesystem uses feature(s) not yet supported in this release.\n" > > _______________________________________________ > xfs mailing list > xfs@xxxxxxxxxxx > http://oss.sgi.com/mailman/listinfo/xfs > _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs