Although this would be an interesting way to drag some of my old NTFS filesystems kicking & screaming into the 21st century, I'd never do one of these in-place

Although this would be an interesting way to drag some of my old NTFS filesystems kicking & screaming into the 21st century, I'd never do one of these in-place conversions again. I tried to go from ext3 to btrfs several years ago - and it would catastrophically fail after light usage. (W're talking less than a few hours of desktop-class usage. In retrospect I think it was `autodefrag/defragment` that would kill it.) I tried that conversion a few times and it never worked, I think I even tried to go from ext3->ext4->btrfs. This was on an Arch install so (presumably) it was the latest and greatest kernel & userspace available at the time. I eventually gave up (/ got sick of doing restores) and just copied the data into a fresh btrfs volume. That worked "great" up until I realized (a) I had to turn off CoW for a bunch of things I wanted to snapshot, (b) you can't actually defrag in practice because it unlinks shared extents and (c) btrfs on a multi-drive array has a failure mode that will leave your root filesystem readonly; which is just a footgun that shouldn't exist in a production-facing filesystem. - I should add that these were not particularly huge filesytems: the ext3 conversion fiasco was ~64G, and my servers were like ~200G and ~100G respectively. I also was doing "raid1"/"raid10" style setups, and not exercising the supposedly broken raid5/raid6 code in any way. I think I probably lost three or four filesystems which were supposed to be "redundant" before I gave up and switched to ZFS. Between (a) & (b) above btrfs just has very few advantages compared to ZFS. Really the only thing going for it was being available in mainline kernel builds. (Which, frankly, I don't consider that to be an advantage the way the GPL zealots on the LKML seem to think it is.)