Problem located.
may_rollback() is still the old codes, while for new convert's metadata,
it's complete OK if it's physical position is different from its logical
space.
Unlike the strict old condition.
I'll add more check to ensure new convert can pass may_rollback() check.
Thanks,
Qu
Qu Wenruo wrote on 2016/05/31 09:13 +0800:
David Sterba wrote on 2016/05/30 17:56 +0200:
Hi Qu,
the convert patchset does not pass a rollback test, fails in the case of
32k nodesize. Thre's not much info why, just 'rollback failed'.
The branch that passes is 'test-rollback', it's current devel without
the convert and low-mem fsck patchsets.
Pretty strange.
As I manually tested a ext4 filled with my /etc, used 32K default
incompat flags, both convert and rollback succeeded without problem.
The same is for convert-tests.sh.
All passed here, just as what we did when developing the patchset.
The commit head I tested is 2a7c68a4e46f4713e746d6e977e9c4cf27913ce3.
Did you have more info on the situation where the rollback fails?
Like the commit head, test method (I assume it's rollback tests from
btrfs-progs)?
Thanks,
Qu
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
