Brad Templeton posted on Wed, 23 Mar 2016 12:10:29 -0700 as excerpted: > It is Ubuntu wily, which is 4.2 and btrfs-progs 0.4.
Presumably that's a type for btrfs-progs. Either that or Ubuntu's using a versioning that's totally different than upstream btrfs. For some time now (since the 3.12 release, ancient history in btrfs terms), btrfs-progs has been release version synced with the kernel. So the latest release is 4.5.0, to match the kernel 4.5.0 that came out shortly before that userspace release and that was developed at the same time. Before that was 4.4.1, a primarily bugfix release to the previous 4.4.0. Before 3.12, the previous actual userspace release, extremely stale by that point, was 0.19, tho there was a 0.20-rc1 release, that wasn't followed up with a 0.20 full release. The recommendation back then was to run and for distros to ship git snapshots. So where 0.4 came from I've not the foggiest, unless as I said it's a typo, perhaps for 4.0. > I will upgrade to > Xenial in April but probably not before, I don't have days to spend on > this. Is there a fairly safe ppa to pull 4.4 or 4.5? In olden days, I > would patch and build my kernels from source but I just don't have time > for all the long-term sysadmin burden that creates any more. Heh, this posting is from a gentooer, who builds /everything/ from sources. =:^) Tho that's not really a problem as it can go on in the background and thus takes little actual attention time. The real time is in figuring out what I need to know about what has changed between versions and if/how that needs to affect my existing config, but that's time that needs spent regardless of the distro, the major question being one of rolling distro and thus spending that time a bit here and a bit there as the various components upgrade, with a better chance of actually nailing down the problem to a specific package upgrade when there's issues, or doing it all in one huge version upgrade, which pretty much leaves you high and dry in terms of fixing problems since the entire world changes at once and it's thus nearly impossible to pin a bug to a particular package upgrade. But meanwhile, as CMurphy says at the expense of a frowny face... Given that btrfs is still maturing, and /not/ yet entirely stable and mature, and the fact that the list emphasis is on mainline, the list kernel recommendation is to follow one of two tracks, either mainline current, or mainline LTS. If you choose the mainline current track, the recommendation is to stay within the latest two current kernel series. With 4.5 out, that means you should be on 4.4 at least, Previous non-LTS kernel series no longer get patch backports at least from mainline, and as we focus on mainline here, we're not tracking what distros may or may not backport on their own, so we simply can't provide the same level of support. For LTS kernel track, the recommendation has recently relaxed slightly. Previously, it was again to stick with the latest two kernel LTS series, which would be 4.4 and 4.1. However, the one previous to that was 3.18, and it has been reasonably stable, certainly more so that those previous to that, so while 4.1 or 4.4 is still what we really like to see, we recognize that some will be sticking to 3.18 and are continuing to try to support them as well, now that the LTS 4.4 has pushed it out of the primary recommended range. But previous to that really isn't supported. Not that we won't do best-effort, regardless, but in many instances, the best recommendation we can make with out-of-support kernels really is to upgrade to something more current, and try again. Meanwhile, yes, we do recognize that distros have chosen to support btrfs on kernels outside that list. But as I said, we don't track what patches the distros may or may not have backported, and thus aren't in a particularly good position to provide support for them. The distros themselves, having chosen to provide that support, are in a far better position to do just that, since they know what they've backported and what they haven't. So in that case, the best we can do is refer you to the distros whose support you are nominally relying on, to actually provide that support. And obviously, kernel 4.2 isn't one of the ones named above. It's neither a mainstream LTS, nor any longer within the last two current kernel releases. So kernel upgrade, however you choose to do it, is strongly recommended, with two other alternatives if you prefer: 1) Ask your distro for support of versions off the mainline support list. After all, they're the ones claiming to support the known to be not entirely stabilized and ready for production use btrfs on non- mainline-LTS kernels long after mainline support for those non-LTS kernels has been dropped. 2) Choose a filesystem that better matches your needs, presumably because it /is/ fully mature and stable, and thus is properly supported on older kernels outside the relatively narrow range of btrfs-list recommended kernels. As for userspace, as explained above, in most cases for online and generally operational btrfs, it's the kernel code that counts. Userspace is important in three cases, however, (1) when you're first creating the filesystem (mkfs.btrfs), (2) if you need relatively new features that older userspace doesn't have the kernelcode calls to support, and (3) when the filesystem has problems and you're trying to fix them with btrfs check and the other offline tools, or you're simply trying to get what you can off the (presumably unmountable) filesystem using btrfs restore, before giving up on it entirely. So for normal use, btrfs userspace version isn't as critical, until it gets so old translating from newer call syntax to older syntax, or between output formats, becomes a problem. But once your btrfs won't mount properly and you're either trying to fix them or recover files off them, /then/ userspace becomes critical, as the newer versions can deal with more problems than older versions can. Meanwhile, newer btrfs-progs userspace is always designed to be able to handle older kernels as well. So a good rule of thumb for userspace is to run at least the latest userspace release from the series matching your kernel version (with the short period after kernel release before the corresponding userspace release excepted, of course, if you're running /that/ close to current). As long as you stay within kernel recommendations, that will keep your userspace within reason as well. So a 4.2 kernel isn't supported (on list, but you can of course refer to your distro instead, if they support it) as it's out of the current kernel support range and isn't an LTS, and upgrading to 4.4 LTS is recommended. Alternatively, you may wish to downgrade to kernel 4.1, which is actually an LTS kernel and remains well supported as such. And once you're running a supported kernel, ensure that your btrfs-progs is the latest of that userspace series, or newer, and you should be good to go. =:^) Again, with the alternatives being either getting support from your distro if they're supporting btrfs on versions outside of those supported on-list, or switching to a filesystem that better matches your use-case in terms of stability and longer term support. > Also, I presume if this is a bug, it's in btrfsprogs, though the new one > presumably needs a newer kernel too. Balance, like most "online" btrfs code, is primarily kernel. All userspace does is call the appropriate kernel code to do the actual work. So the problem here is almost certainly kernel. Meanwhile, I have an idea of what /might/ be your balance problem, but I want to cover it in a separate reply. Suffice it to say here that the news isn't great, if this is your issue, as it's a known but somewhat rare problem that has yet to be properly traced down and fixed. -- 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
