On 11/04/2016 07:01 AM, Saša Janiška wrote: This list is aimed at current (and past) Fedora releases. While F25 is very near release right now, it hasn't been released yet. Your question would be better suited for the fedora developer list: devel(a)lists.fedoraproject.org They could probably help more over there. That being said, I don't think btrfs on /boot is part of the plan for F25, although I could be wrong on that. ---------------------------------------------------------------------- - Rick Stevens, Systems Engineer, AllDigital ricks(a)alldigital.com - - AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 - - - - "Hello. My PID is Inigo Montoya. You `kill -9'-ed my parent - - process. Prepare to vi." - ----------------------------------------------------------------------

On Fri, Nov 4, 2016 at 11:01 AM, Saša Janiška <gour(a)atmarama.com&gt; wrote: Fedora/RedHat's stance on btfs is "passive agressive" (Not Invented Here Syndrome). I suggest you use SUSE or OpenSUSE where BTRFS is a first class citizen since 2009. Dec 2012: SUSE says btrfs is ready to rock https://www.linux.com/news/suse-linux-says-btrfs-ready-rock Facebook will soon roll out btfs on production systems http://www.phoronix.com/scan.php?page=news_item&px=Facebook-More-Btrfs Dec 2014: With btrfs the default on OpenSUSE will other distros follow suit? http://linuxbsdos.com/2014/12/02/with-btrfs-the-default-on-opensuse-when-... "Snapper, the excellent Btrfs management tool, is yet another of SUSE Linux's best-kept secrets" https://www.linux.com/news/snapper-suses-ultimate-btrfs-snapshot-manager Don't get me wrong, there are many things to like about RedHat/Fedora, but BTRFS support is not one of them. FC -- During times of Universal Deceit, telling the truth becomes a revolutionary act - George Orwell

On Mon, Nov 07, 2016 at 07:30:54PM -0300, Fernando Cassia wrote: That's absolutely not true. Fedora has wanted to use Btfs since... one of the Boston FUDCons in 2008 or 2009. It's just never been ready, which is something we know because we kept asking the upstream devs and they kept saying "not yet, please", until they finally said "look, please stop asking". Meanwhile RHEL (and Fedora Server) use XFS, which was *definitely* not invented at Red Hat or by Fedora. While I definitely disagree with your characterization above, this I do agree with. -- Matthew Miller <mattdm(a)fedoraproject.org&gt; Fedora Project Leader

Matthew Miller <mattdm(a)fedoraproject.org&gt; writes: :-) Well, I did try btrfs on openSUSE ~1yr ago with 13.2 and then with Tumbleweed and although using snapper for supposedly easy-rollback after broken update, I had experience that update to GNOME did break my desktop and was not able to recover it despite having several snapshots which finally led me (back) to Debian. With Debian (Sid), however, isntaller cannot cope with btrfs for anyhting more than basic hard disk layouts…in my case I wanted to do btrfs/raid1 using subvolumes for @root and @home - something which Anaconda did very well, so from my experience I’d say that Fedora’s support is superb. ;) Sincerely, Gour -- He who is satisfied with gain which comes of its own accord, who is free from duality and does not envy, who is steady in both success and failure, is never entangled, although performing actions.

I've been told repeatedly that BTRFS isn't production ready. I've used it here on a handful of servers and had nothing but trouble with it, stability-wise. I sure as hell wouldn't use it on /boot if I can't trust it for /home or /. On Tue, Nov 8, 2016 at 9:15 AM, Fernando Cassia <fcassia(a)gmail.com&gt; wrote: -- Mark Haney ::: Senior Systems Engineer *VIF* *International Education* P.O. Box 3566 ::: Chapel Hill, N.C. 27515 ::: USA 919-265-5006 office Global learning for all. www.viflearn.com Find VIF on Facebook <http://facebook.com/VIFInternationalEducation> | Twitter <https://twitter.com/vifglobaled> | LinkedIn <http://www.linkedin.com/company/vif-international-education> Recognized as a ‘Best for the World’ <http://bestfortheworld.bcorporation.net/> B Corp!

2016-11-08 19:00 GMT+01:00, Fernando Cassia <fcassia(a)gmail.com&gt;: I know nothing about btrfs. But I do know that there's a difference between a piece of software "not being bug-free" and the upstream devs saying it's not yet ready. See Matthew's post upthread.

On Tue, Nov 08, 2016 at 01:44:00PM -0500, Mark Haney wrote: Hey, maybe time to step back from the email a little bit. This isn't an acceptable way to talk on Fedora mailing lists. -- Matthew Miller <mattdm(a)fedoraproject.org&gt; Fedora Project Leader

Some of this is a repeat, as this comes up from time to time. Neither Red Hat nor Fedora currently have Btrfs developers to manage any Btrfs regressions that come up. And as the upstream development is still very busy, there are regressions, and there's every reason to believe Fedora users would get disproportionately impacted because Fedora kernels tend to be very recent. SUSE is in a sweet spot because they have a bunch of Btrfs developers, and they are running longterm kernels. So it is upstream testers, including Fedora using testers, who hit regressions, get them reported and fixed before they could ever appear in a longterm kernel on any of the SUSE offerings. And because of their strong Btrfs developer presence, they're doing a lot of stable backports. I think Fedora could soon do Btrfs with single device only. But I think it requires community work to build Btrfs regression tests (these exists already) within Fedora infrastructure, so that every built kernel runs those tests. And then some interpretation is needed to know whether a particular failure is tolerable, users need notification, or the build needs to be failed. The details of this need to be reviewed by the kernel team. Right now they can't do that work themselves, they have plenty on their plate now. As for stability, it's kinda complicated. Single device Btrfs is stable, unless the device lies about committing to disk when it hasn't, and as it turns out devices do transiently corrupt data. Btrfs is going to give a heads up when that happens, and if it's bad, as in further writes can corrupt the filesystem, it'll go read only. Other filesystems tolerate this condition far longer. What's interesting is both XFS and ext4 now default at mkfs time to checksumming metadata. So they can catch similar problems, just not corruption with actual file data which is a much larger target, and can still cause further system corruption if it goes unchecked. Anyway, since using it as primary filesystem for roughly 5 years, I've had no problems on single device Btrfs that weren't user induced. On raid1 and raid 10 I have found meaningful bugs and deficient features, that a user can innocently run into, despitere being known and documented. But in those cases, while i lost redundancy, no data was lost or corrupted. Meanwhile the Btrfs list still fields weird failure in occasion. Steps for repairing Btrfs if it face plants is really non obvious. It's a lot like throwing spaghetti at a wall (even though that's not how you should test your spaghetti people!) Eventually the idea is, kernel code should not f up in the first place even if the device lies, but even if it goes badly, can recover and fix itself without fsck. The fsck is really something of a debugging and time saving tool. Not the ideal scenario. Consider that Btrfs is supposed to scale, and none of the current raid levels scale, and fsck doesn't scale either, nor does scrub, or balance. So Btrfs is going to keep changing and getting better. -- Chris Murphy