btrfs-progs: convert: Rework rollback
authorQu Wenruo <quwenruo@cn.fujitsu.com>
Thu, 23 Feb 2017 08:21:14 +0000 (16:21 +0800)
committerDavid Sterba <dsterba@suse.com>
Thu, 16 Mar 2017 16:02:44 +0000 (17:02 +0100)
commit6d881033e1651a59970fa52d365b3268decab1d1
treeadbada6c898620c0d6867549a69c58320dea61ac
parent1170ac3079005a99098e48777513e5ab09b64d55
btrfs-progs: convert: Rework rollback

Rework rollback to a more easy to understand way.

New convert behavior makes us to have a more flex chunk layout, which
only data chunk containing old fs data will be at the same physical
location, while new chunks (data/meta/sys) can be mapped anywhere else.

This behavior makes old rollback behavior can't handle it.
As old behavior assumes all data/meta is mapped in a large chunk, which is
mapped 1:1 on disk.

So rework rollback to handle new convert behavior, enhance the check by
only checking all file extents of convert image, only to check if these
file extents and therir chunks are mapped 1:1.

This new rollback check behavior can handle both new and old convert
behavior, as the new behavior is a superset of old behavior.

Further more, introduce a simple rollback mechanisim:
1) Read reserved data (offset = file offset) from convert image
2) Write reserved data into disk (offset = physical offset)

Since old fs image is a valid fs, and we only need to rollback
superblocks (btrfs reserved ranges), then we just read out data in
reserved range, and write it back.

Due to the fact that all other file extents of converted image is mapped
1:1 on disk, we put the missing piece back, then the fs is as good as
old one.

Then what we do in btrfs is just another dream.

With this new rollback mechanisim, we can open btrfs read-only, so we
won't cause any damage to current btrfs, until the final piece (0~1M,
containing 1st super block) is put back.

Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
[ port to v4.10 ]
Signed-off-by: David Sterba <dsterba@suse.com>
convert/main.c
ctree.h
file.c