On Thu, Jun 02, 2016 at 08:38:03AM +0800, Qu Wenruo wrote: > > > At 06/01/2016 09:49 PM, David Sterba wrote: > > On Wed, Jun 01, 2016 at 04:29:43PM +0800, Qu Wenruo wrote: > >> New convert doesn't insert holes for superblock migration range. > >> > >> Unlike old design, which only relocate 4K(superblock size) to other > >> places. > >> In new design, to make sure convert can handle different page size and > >> align chunk bytenr, we relocate the whole 64K range. > > > > This looks like a potential backward compatibility problem. In the > > unlikely scenario, mixing old and new convert to do conversion and > > rollback. Did you try that? > > Tried, old convert + new rollback is fine. > Although for new convert + old rollback, it may fail to rollback some > converted case. > > But I didn't consider new convert + old rollback will be a normal use case. It's not meant to be a normal use case, but such thing can happen so I want to know how it behaves. If old convert rollback fails on new image, then it's ok, ie. we want to prevent accidental damage. > For old converted fs, it's pretty strict for may_rollback(). > Almost all ext2 image file extent must be 1:1 mapped, except the first > 1M and backup superblocks. > > While for new convert, it exception range is larger, 0~1M is the same, > while for backup superblocks, its range is extended from 4K to 64K. > > So new convert is compatible with old convert and is able to rollback > old converted fs. This could possibly happen so good that it works in that direction. -- 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
