Summary: | sys-fs/btrfs-progs-0.19-r3: cannot rollback from btrfs to ext4 (git version works) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Alexander E. Patrakov <patrakov> |
Component: | [OLD] Core system | Assignee: | Joe Peterson (RETIRED) <lavajoe> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | chutz+bugs.gentoo.org, dblaci, dschridde+gentoobugs, marduk, nbowler |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 424605 |
Description
Alexander E. Patrakov
2012-06-10 12:22:19 UTC
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. |