| Message ID | 1427336364-18161-1-git-send-email-quwenruo@cn.fujitsu.com (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
-------- 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 -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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...
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::
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 <vytdau@gmail.com> Reported-by: Tsutomu Itoh <t-itoh@jp.fujitsu.com> Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com> --- v2: Add reporters. --- Documentation/btrfs-convert.txt | 9 +++++++++ 1 file changed, 9 insertions(+)