On Sun, Jan 31, 2016 at 5:35 AM, Christian Pernegger <perneg...@gmail.com> wrote: > On 31 January 2016 at 02:42, Chris Murphy <li...@colorremedies.com> 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.
The Debian wiki on Btrfs basically defers to upstream. And upstream Btrfs recommends using newer kernels than this. Part of it is that there have been literally thousands of changes, there are hundreds of bugs discovered and fixed since that kernel version. Another part is there so much change no one likely has any idea how to cross reference the changes with your particular problem. So the request is to use something newer because it's a practical compromise. Dollars to donuts only a developer would know such details and yet surely such a detail is lost among thousands of others because by now 3.16 is ancient history. At the very least, you should find a way to use btrfs-progs 4.4, 'btrfs check' (without --repair) against this volume, and report the results. That's safe. The easiest way I can think to do it is a Fedora nightly. I just tested this one: https://kojipkgs.fedoraproject.org/mash/rawhide-20160130/rawhide/x86_64/os/images/boot.iso It has kernel 4.4rc1+ and btrfs-progs 4.4. You can boot from the troubleshooting menu, rescue option, and choose option 3 "Skip to shell" and then run btrfs check, again without --repair. This ISO boots BIOS and UEFI systems, just dd it to a stick. If that comes up clean you can even mount the volume and scrub it (the scrub code is kernel code even though it's activated by user space tools; whereas the fsck is in the user space tools). -- Chris Murphy -- 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
