Zach Fuller posted on Mon, 28 Dec 2015 18:08:12 -0600 as excerpted: > I have grabbed the "btrfs-progs-git" package from the AUR, which should > contain the devel branch. > $ sudo btrfs --version btrfs-progs v4.3.1-31-g0ab3d31 > > I ran "btrfs check --repair" again on the drive, and no "type mismatch > with chunk" errors were returned.
So Chris A Mitterer's belief that the fix was in integration but not released yet seems to be correct. [snip some output with free-space-cache errors] > I'm not sure what the output of the above check means, but there are > certainly less errors than before. Should I be worried about these "free > space cache" errors? No. Free-space-cache errors get detected and fixed in normal use, so the check output for them is primarily informational. > It seems that the newer version of "btrfs-progs" from the devel branch > fixed the problem. The drive still mounts and functions correctly. > Should I continue to run the devel branch, or should I switch back to > the main branch? I would prefer to have a stable system rather than > being on the bleeding edge. That's an interesting question, the answer to which ultimately depends on your own definitions of stable as opposed to bleeding edge. However, given that you're running Arch, not some mostly half-decade-old enterprise distro with fixes backported, I imagine your definition of "stable" can't be /too/ conservative. The fact is that as widely accepted on the list, btrfs itself, while no longer "experimental" "eat your babies" unstable, remains "still stabilizING, not yet fully stable and mature." As such, people really interested in "stable", as in those people mentioned above that are running half decade old enterprise distros with fixes backported, really shouldn't be running it at all. Tho some such distros are choosing to support btrfs, which is their business, but then the people running those distros and using their btrfs should really be getting support from them, not from the list, since on the list we don't generally consider btrfs suitably stable for that, and only the distros know what they're backporting to their nominally really old kernel and userspace version numbers anyway, so the list really /can't/ properly support them. But like I said, you're running arch, which itself indicates that you're not enterprise-level stal^hble conservative. And you're running btrfs, which assuming you did your research before just jumping into, indicates, as does the fact that you actually did try the live-git integration version when necessary, that you /are/ willing to go live-git when necessary (or alternatively wait for a fix to hit mainline, as some users do when the btrfs they need fixed isn't critical to daily operations), even if you prefer not to do it longer term. And being an informed btrfs user who knows its current status, you presumably also either have tested backups or are willing to declare what was on that btrfs lost if worse comes to worse. With that in mind, I'd suggest that like me here on gentoo, you could run current btrfs release userspace and release or rc kernels, and simply be prepared to build a live-git version or possibly revert to an older version, if you run into a bug where it's necessary. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
