Re: [PATCH v2 2/3] btrfs-progs: convert: Rework rollback to handle new convert image

[Chandan Rajendra <chandan@linux.vnet.ibm.com>]

On Thursday, December 15, 2016 05:03:30 PM Qu Wenruo wrote:
> Although commit 9c4b820412746b3 tried to make the rollback condition
> less restrict, to co-operate with new rollback behavior, it's still too
> restrict.
> 
> If btrfs allocates a new data chunk, it's highly possible that the new
> chunk will not be 1:1 mapped anymore.
> 
> And this makes old rollback check fails, and refuse to rollback.
> 
> This patch rework it by checking rollback condition more accurately.
> 
> 1) Rollback condition
>    Unlike old chunk level check, we use file extent level check.
>    So we manually check every file extents of convert image file.
> 
>    Only when all file extents except ones in btrfs relocated ranges(*)
>    are mapped 1:1 we allow rollback.
> 
>    This behavior make both old and new behavior happy.
> *:
>    [0, 1M)
>    [btrfs_sb_offset(1), +64K)
>    [btrfs_sb_offset(2), +64K)
> 
> 2) Rollback method
>    Old rollback method is quite complex, using extent_io tree to mark
>    every checked ranges.
>    And do extra chunk tree operation before rollback.
> 
>    The new rollback method is quite simple.
>    1) open btrfs
>    2) read and save relocated data
>    3) close btrfs
>    4) write relocated into place.
> 
> Such rework fixes the following problem
> 1) rollback failure after new data chunk allocation
> 2) rollback failure after correct NO_HOLES convert

Hi Qu,

With this patch applied, I get the following on an x86_64 machine,

[root@localhost]~/btrfs-progs# btrfs-convert -r /dev/loop0
ctree.c:1112: btrfs_search_slot: Warning: assertion `p->nodes[0] != NULL` failed, value 1
btrfs-convert(btrfs_search_slot+0x117)[0x40c906]
btrfs-convert(btrfs_lookup_dir_item+0x70)[0x41d902]
btrfs-convert(main+0x5e2)[0x43af50]
/lib64/libc.so.6(__libc_start_main+0xf0)[0x7f7fb6168700]
btrfs-convert(_start+0x29)[0x408a69]
extent buffer leak: start 67305472 len 16384
rollback complete

The same error occurs on a ppc64 machine when using 64k sectorsize.

The three 'rollback' patches were applied on top of commit
9ce512ac57cb08edf2f742da085c383834f804dd (i.e. btrfs-progs: check: Fix false
alert on generation mismatch for tree reloc tree) that is available on David's
devel branch.

-- 
chandan