-------- Original Message --------
Subject: Re: [PATCH v2] btrfs-progs: Doc: Add warning and note on
btrfs-convert.
From: David Sterba <dste...@suse.cz>
To: Qu Wenruo <quwen...@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
--
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
