I converted my ext4 filesystem to btrfs, then used it for some time, and became dissatisfied with btrfs performance. So I decided to rollback to ext4, by running this command while the fs is not mounted: btrfs-convert -r /dev/sda1 Result: couldn't open because of unsupported optional features(2). btrfs-convert: disk-io.c:682: open_ctree_fd: Assertion `!(1)' failed. Aborted (core dumped) On #btrfs darksatanic blamed gentoo for packaging btrfs-progs from 2010. The only working version is a git checkout. Reproducible: Didn't try It may be relevant to the bug that I have added some snapshots and other subvolumes since the initial conversion, redefined the default subvolume, and that I have mounted it at least once with linux-3.4.0 using the space_cache and/or inode_cache options. space_cache does change the on-disk format, so it may well be the source of the unsupported optional feature.
The snapshotted version also does not support creating read-only snapshots (the last I tried).
I disagree with the severity changing. critical = crashes or causes data loss "Aborted (core dumped)" - here is a crash very slow (10 minutes) mounting + promised but non-working ability ro rollback = data loss unsolvable without updating to a git version.
This version of btrfs-progs is fairly old now (even though, yes, it should work without such issues, of course). Have you tried the live build (btrfs-progs-9999)? I am curious if this is an old bug that might have been fixed. Since btrfs is still considered experimental, I'd be wary of doing such filesystem in-place conversions on data that is valuable. I have never tried converting to/from ext4. My general recommendation (and what I use) is the live build. If you can try again to reproduce with 0.19 and the live one, that would help. If not, we may not be able to track this one down.
I have not tried the live ebuild, but I think it would have worked, because compiling manually from git worked. In fact, this bug is about the mismatch between the kernel and non-live versions of btrfs-progs leading to their complete inabilty to work on filesystems touched by recent kernels. Please make a git snapshot and package.mask all other versions of btrfs-progs.
I agree and have masked 0.19. We cannot make a git snapshot, however, unless upstream has versioned it. Since there is sensitivity to matches with kernel code, I'd rather not guess at compatibility. Other distros have chosen a specific version (e.g. variants of 0.19, as we did before), but clearly this is a bit dangerous. I see no alternative except for users to use the live build. I have been using the live one for some time now, and it works well. Btrfs is experimental, so I think this is OK for now until a better solution is found. I've marked this bug "fixed" by masking the old build, even though I would like a better fix. :)
The resolution of this bug impact stable sys-block/gparted with USE=btrfs and sys-kernel/dracut with DRACUT_MODULES="btrfs"
So, the recommended solution is to build the live version of btrfs-progs, which in turn will build from git HEAD, which currently also happens to be a branch named "dangerdonteveruse". Ouch! http://git.kernel.org/?p=linux/kernel/git/mason/btrfs-progs.git;a=shortlog;h=refs/heads/dangerdonteveruse
It would be also nice if we can at least get the live build keyworded.
I have contacted upstream to see what their recommendation is. We'll leave this open, since there is not a satisfactory solution as-yet. Stay tuned.
OK, a better solution is now in place. After discussing with upstream, I have added a new btrfs-progs-0.19.11, which matches the latest version in the Fedora tree. This is based on a particular hash in the git sources. From now on, we will follow Fedora, upstream's versioning (if they start numbering them again), or another logical source. I have unmasked 0.19 and will keep it until we stabilize 0.19.11.
