Re: [PATCH v2] btrfs-progs: Doc: Add warning and note on btrfs-convert.
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
Re: [PATCH v2] btrfs-progs: Doc: Add warning and note on btrfs-convert.
David Sterba posted on Thu, 02 Apr 2015 17:19:31 +0200 as excerpted: 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. 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? Is defrag ever going to be snapshot-aware-enabled again? If not, then I don't see that (snapshot-unaware) defrag can affect ext2_saved either. But with snapshot-aware-defrag, AFAIK defrag would affect ext2_saved, unless of course it was special-cased... -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- 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
Re: [PATCH v2] btrfs-progs: Doc: Add warning and note on btrfs-convert.
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? -- 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
[PATCH v2] btrfs-progs: Doc: Add warning and note on btrfs-convert.
Although btrfs-convert can rollback converted btrfs, it still has some limitation to ensure rollback. Add a warning on the limitations. Also add a note for users who decides to go on with btrfs and don't need the rollback ability. Reported-by: Vytautas D vyt...@gmail.com Reported-by: Tsutomu Itoh t-i...@jp.fujitsu.com Signed-off-by: Qu Wenruo quwen...@cn.fujitsu.com --- v2: Add reporters. --- Documentation/btrfs-convert.txt | 9 + 1 file changed, 9 insertions(+) diff --git a/Documentation/btrfs-convert.txt b/Documentation/btrfs-convert.txt index 8b3f05b..bb2f020 100644 --- a/Documentation/btrfs-convert.txt +++ b/Documentation/btrfs-convert.txt @@ -15,6 +15,15 @@ DESCRIPTION and the original filesystem image is accessible as from separate subvolume named 'ext2_saved' as file image. +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. + +NOTE: If one is satisfied with converted btrfs, and not longer wants to +rollback to ext*, it is highly recommended to remove 'ext2_saved' subvolume +and execute *btrfs filesystem defragment* and *btrfs balance* command on the +converted btrfs. + OPTIONS --- -d|--no-datasum:: -- 2.3.4 -- 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