Christian Pernegger posted on Sun, 31 Jan 2016 13:35:58 +0100 as excerpted: > On 31 January 2016 at 02:42, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> > wrote: >> On Sat, Jan 30, 2016 at 2:19 PM, Christian Pernegger It maybe be stable >> for Debian but is Debian explicitly supporting Btrfs with this release? >> I don't think they are. > > The modules are in the kernel, the progs are in the main archive, it's > an option in the installer. It's not the default fs but I couldn't find > any indication that it's more or less supported than, say, xfs. > Why they've chosen 3.16 (and not 3.18, which would be a long term > release) I don't know, but the fact remains that that's the default > kernel of a tier 1 distro, so people using it are going to be around for > a while. [To pernegger@ and list both, as requested.] What the distro wishes to support is of course up to the distro. See below. >> But absolutely, of course we hope the problem is gone with the newer >> version, *that's how file system development works.* > > Be that as it may, as I said, that approach doesn't inspire confidence. > If I had the vaguest idea about how to reproduce it, sure, but all I > have is an apparently lightly corrupted or at the very least glitchy fs > (it mounts and unmounts just fine). How would I know if a new kernel > helped things? Umm... Because you _try_ it? And if you're not willing to _try_ it, why on earth are you running a still stabilizing, not fully stable and mature, filesystem, where the recommendation is to stay at least reasonably current as there's still bugs being actively fixed? >> I can see how it might seem like it's a reasonable question to just ask >> first, but it really isn't. There's just so much development happening >> right now, a developer is not in a great position to think that far >> back for specific problems and whether yours might be one of them, and >> in what kernel version it was fixed. *shrug* just doesn't work that >> way, that's why there are changelogs for every sub kernel version. > > I do understand your point of view, but: If a possible fs corruption bug > on a widespread (if older) kernel after one month of use and without any > discernible cause gets nothing more than *shrug* from this list then > btrfs isn't production ready nor ready for any kind of day-to-day use, > not because of code maturity but because of that mindset. IMHO the > btrfs-genie is too far out of the bottle for that, > the wording of the stability status on the wiki much too inviting. I know of no list regular claiming btrfs is production ready or fully stable. In fact, the general position here is that btrfs is _not_ production ready, and that while btrfs is "stabilizING", it is "not yet fully stable and mature." Yes, depending on the use-case, btrfs is or can be ready for routine daily use, provided people are aware of the situation, and are following the sysadmin's first rule of backups, which in simplest form says that if you don't have at least one backup, by definition of your (in)action, you are defining that data as worth less than the time/hassle/resources necessary to do that backup. Of course that's the first rule of backups even if you're running on a fully stable and mature filesystem, and because btrfs isn't at that point yet, having at least one backup, and preferably more (because with btrfs not fully stable and mature, it can't be considered reliable as the primary working copy either, more a test deployment, which effectively makes the first backup the primary working copy, which means if it isn't backed up, thus a second backup, you're still defining the data as of little more than trivial value. Additionally, given the stability situation, here on this list we generally rather strongly recommend that people run either the latest or at the oldest, the first back, of either the current kernel series or the LTS kernel series. With the just released 4.4 an LTS kernel, and 4.1 the previous LTS, that means for best support here, and of course 4.4 current and 4.3 the previous current, that means for best support here, we're now recommending no older than the 4.4 or 4.1 LTS kernel series, or the 4.4 or 4.3 current kernel series, tho with 4.4 so new, it's understandable if people are still on the second-back LTS, 3.18, provided they're already working on upgrading to LTS-4.1. Of course we still do our best if people are running older than that, but because btrfs is still moving fast and older kernels have known bugs that are fixed in newer versions, previous to that is ancient history for us, and we're simply not able to support it to the same level we do the recommended kernels. As such, people should expect that as soon as they have a problem, the first thing they're going to be asked to do is upgrade to something newer than the btrfs Paleolithic era (OK, I'm exaggerating a bit, Neolithic, then) and see if the problem is already fixed. Of course what distros choose to support is up to them, and some are indeed supporting older btrfs, backporting fixes, etc. But in that case people really should be getting their btrfs support from them as well, because they're best positioned to know what fixes they've backported to whatever arbitrary kernel version number they're using, while all we know is what mainline code of a comparable version was like. Then of course there's the userspace tools, btrfs-progs. While on a normal runtime kernel the kernel code is what counts as userspace primarily simply makes calls to the kernel and the kernel does all the work, as soon as you're using userspace to try to work with an offline btrfs, btrfs check, btrfs restore, etc, it's userspace code doing the work, and then running current userspace becomes critical, as again, it has all the bugfixes that older versions lack. While both kernels and userspace are designed to work with both older and newer versions of the other, a good rule of thumb for userspace is to keep its version at least in sync with your kernel version. That way, provided you're following the kernel recommendations of no more than one LTS kernel series back from the current LTS kernel series, userspace won't get too outdated, either. As for old and stable, yes, there's legitimate reasons to want to run old and stable. However, they tend not to be very compatible with wanting to run a new and still stabilizing filesystem that's not yet mature, since the filesystem code is still moving fast and there are /real/ bugs being fixed every release. Thus, the general recommendation, on-list at least, is to pick one or the other, and if you pick old and stale^h^hble, forget about btrfs for the time being. Again, what your distro may support and whether you choose to use that support is between you and the distro, but then, you really are probably better off actually using that distro support, since they're the ones that know what they've backported, etc, and not the list, where our focus is on further stabilization in reasonably current mainline current or LTS series kernels. -- 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
