Russell Coker wrote:
I've got some filesystems I want to convert to BTRFS. I recall someone saying that BTRFS had some issue with lots of symlinks, I have a filesystem with 200G of data in 1,400,000 Inodes that's used by "cp -rl" copies of an rsync backup - would this be an issue?
IIRC it it *hard* links, and only matters if there are a lot in the same dir. Where "a lot" is something like 30. Something about storing back-references within the dir's inode, and there not being enough space and it not (yet) knowing how to allocate more space for the inode metadata. I guess my memory is fuzzier than I thought when I started replying :-( http://bugs.debian.org/645009 is an example.
Also how much space should there be available for a conversion from Ext4 to BTRFS?
If you are converting in-place, the old ext4 metadata stays there as a snapshot, which you can then delete. IIRC it is better to provision a new btrfs and copy the data in, than to convert in-place. Perhaps just doing a btrfs rebalance afterwards would fix that.
Obviously the default of two copies of metadata gives the potential for a conversion to run out of disk space. What happens when btrfs-convert finds that it doesn't have enough disk space, can it be relied on to give a result of either an Ext4 or a BTRFS filesystem that is correct and contains all the data?
AFAIK in-place conversion doesn't touch any of the existing used data/metadata blocks, it just creates new ones. After successful conversion, you can still mount it as ext4 (although doing so -o rw would probably do bad things). I would be surprised if an ENOSPC during conversion could break the ext-y-ness of the fs.