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.
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.
Although old convert can't rollback new converted fs.
And if there is only a 4K used block inside 64K superblock migration range, it
will make converted fs has discontinuous file extents.
This patch will fix it by inserting needed holes to avoid such
discontinuous error.
Reported-by: Tsutomu Itoh <t-i...@jp.fujitsu.com>
Signed-off-by: Qu Wenruo <quwen...@cn.fujitsu.com>
---
David, I'm very sorry, all these recently exposed bugs are related to
superblock migration range, and will only be triggered by special build
ext* images(Needs special space range be allocated in ext*)
I'll try my best to create the minimal trigger e2image dump, our current
image is too large for test cases.
Well, given the amount of last minute fixes I'm now hesitant to do 4.6
release with this patchset.
I'm really sorry for that.
Thanks,
Qu
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
