Eric Sandeen wrote:
> Christoph Hellwig wrote:
>> On Tue, Dec 01, 2009 at 01:17:55PM -0600, Eric Sandeen wrote:
>>> + if (xfs_sb_has_mismatched_features2(&tsb)) {
>>> + dbprintf(_("Superblock has mismatched features2 fields, "
>>> + "skipping modification\n"));
>>> + return 0;
>>> + }
>> However I'm not sure if this one is an all that good idea. It'll make
>> all version updates fail if we have a mismatched features2. That way
>> people can't use xfs_db to fix it up which seems odd.
>>
>> To me just printing the warning but not aborting would be the best way
>> to inform the user about it.
>
> hm yeah I suppose so.
>
> I wonder if we should catch it somehow on the feature-set shortcuts
> like "attr1" but allow it for explicit value sets ...
actually:
"version" prints version
"version <featurename>" adds that feature
"version <value> <value>" prints the names for the values but doesn't change
anything
... so you can still modify mismatched values by writing to the superblocks
directly although that's a little tedious. But that shouldn't really happen
too often.
I'm just wary of automatically overwriting the mismatch w/o errors... it seems
like some intervention might be necessary.
Or, since the kernel does this already (fixes up mismatches) maybe we should
just put the same algorithms into xfs_db but that's getting tricky. :)
Maybe for a later date ...
-Eric
> ?
>
> -Eric
>
>>> +
>>> if ((version & XFS_SB_VERSION_LOGV2BIT) &&
>>> !xfs_sb_version_haslogv2(&tsb)) {
>>> tsb.sb_logsunit = 1;
>>> @@ -564,7 +570,8 @@ do_version(xfs_agnumber_t agno, __uint16_t version,
>>> __uint32_t features)
>>>
>>> tsb.sb_versionnum = version;
>>> tsb.sb_features2 = features;
>>> - fields |= XFS_SB_VERSIONNUM | XFS_SB_FEATURES2;
>>> + tsb.sb_bad_features2 = features;
>>> + fields |= XFS_SB_VERSIONNUM | XFS_SB_FEATURES2 | XFS_SB_BAD_FEATURES2;
>> This one looks good to me.
>>
>
> _______________________________________________
> xfs mailing list
> xfs@xxxxxxxxxxx
> http://oss.sgi.com/mailman/listinfo/xfs
>
|