On Mar 3, 2014, at 11:24 AM, Michael Russo <mike@xxxxxxxxxxxxxx> wrote: > Duncan <1i5t5.duncan <at> cox.net> writes: >> >> That allows rollback if desired, but does tie up some some space with the >> automatically created btrfs "snapshot" that contains the ext3/4 metadata >> and untouched data. > > Nope, I definitely deleted the snapshots, running btrfs sub list > gives me nothing back: > > root@ossy:/usr/src/btrfs-progs# /usr/src/btrfs-progs/btrfs sub list /mymedia > root@ossy:/usr/src/btrfs-progs# > > Thanks for the detailed reply though. While doing this operation I > wanted to not have any snapshots so that I needed the minimum > amount of space to do the rebalance. > > But this all does seem strange right? Why the heck would it refuse > to move these 70GB and think there are 0 blocks of free space? It might be worth adding enospc_debug as a mount option and then retrying the balance -dconvert=raid1,soft which should only try to balance unconverted data chunks. The metadata all looks converted to raid1. The debug output probably only means something to a developer but maybe it'll be enlightening. Slightly off-topic to your question is whether btrfs-convert is expected to be a recommended method of migrating from ext3/4 or if it's more proof of concept that ought to work? The current version uses the ext block size for btrfs leaf size, rather than the 16KB default leaf size by mkfs.btfs. David Sterba was working on this at one point. Also I don't think btrfs-convert yet enables extref, although it can be enabled with btrfs-tune after conversion. In any case, the conversion isn't quite the same thing as you get with a new file system. Chris Murphy -- 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
