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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
