Re: [PATCH v2] btrfs-progs: Doc: Add warning and note on btrfs-convert.

[Qu Wenruo <quwenruo@cn.fujitsu.com>]

-------- Original Message  --------
Subject: Re: [PATCH v2] btrfs-progs: Doc: Add warning and note on 
btrfs-convert.
From: David Sterba <dsterba@suse.cz>
To: Qu Wenruo <quwenruo@cn.fujitsu.com>
Date: 2015年04月02日 23:19

> On Thu, Mar 26, 2015 at 10:19:24AM +0800, Qu Wenruo wrote:
>> +WARNING: To ensure *btrfs-convert* be able to rollback btrfs, one should never
>> +execute *btrfs filesystem defragment* or *btrfs balance* command on the
>> +converted btrfs.
>
> So it looks like a fundamental problem, not lack of implementation. The
> original filesystem has some correspondence between physical blocks (1:1
> match in ext) and btrfs blocks (where the mapping is not 1:1, though
> from the beginning physical matches logical).
>
> Once we balance data, the chunks get moved and the original phyisical
> offset is lost. We'd have to remember that somewhere and restore upon
> rollback.
>
> I don't see now why defrag is harmful to rollback. The defragmented data
> are written to the "ext free space", ie. where all new modifications get
> written. The old data are pinned by the ext2_saved subvolume and can be
> restored. Or not?
>
Oh, I forgot ext*_image is readonly, so defrag should be OK.

I'll remove defrag from warning.

BTW, although we use 1:1 physical bytenr and if the extent is moved, we 
lost its physical bytenr, but we still have its offset in ext*_image, 
and its logical file offset is the same as its original physical bytenr.

So, why not use file offset as physical bytenr to do rollback?
It should make btrfs-convert to rollback even after balance.

Thanks,
Qu