/boot on btrfs

[Gour]

Hello,

I plan to put Fedora very soon on my desktop machine to replace Debian,
but noticed that /boot on btrfs is not supported although, iirc, I was
using the same setup under both openSUSE and Debian when using btrfs.

At the moment I do use xfs/raid1, but considering to switch (back) to
btrfs since simplifies setup having features of both lvm+raid.

However, the need for separate /boot makes is a little cummbersome…there
is one issue in regard:
https://bugzilla.redhat.com/show_bug.cgi?id=864198 so wonder if there is
possibility to have support for /boot on btrfs in f25?

Sincerely,
Gour

[Rick Stevens]

On 11/04/2016 07:01 AM, Saša Janiška wrote:
> Hello,
>
> I plan to put Fedora very soon on my desktop machine to replace Debian,
> but noticed that /boot on btrfs is not supported although, iirc, I was
> using the same setup under both openSUSE and Debian when using btrfs.
>
> At the moment I do use xfs/raid1, but considering to switch (back) to
> btrfs since simplifies setup having features of both lvm+raid.
>
> However, the need for separate /boot makes is a little cummbersome…there
> is one issue in regard:
> https://bugzilla.redhat.com/show_bug.cgi?id=864198 so wonder if there is
> possibility to have support for /boot on btrfs in f25?

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:

[e-mail]

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    [e-mail] -
- AIM/Skype: therps2        ICQ: 226437340           Yahoo: origrps2 -
-                                                                    -
-    "Hello. My PID is Inigo Montoya.  You `kill -9'-ed my parent    -
-                     process.  Prepare to vi."                      -
----------------------------------------------------------------------

[Gour]

Rick Stevens  writes:
> 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.

OK. I sill installed f25 with btrfs and separate /boot (raid1 setup). ;)

Sincerely,
Gour

[Fernando Cassia]

On Fri, Nov 4, 2016 at 11:01 AM, Saša Janiška  wrote:
> At the moment I do use xfs/raid1, but considering to switch (back) to
> btrfs since simplifies setup having features of both lvm+raid.

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-wil...

"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

[Fernando Cassia]

On Mon, Nov 7, 2016 at 7:30 PM, Fernando Cassia  wrote:
> since 2009.

sorry, that should have read 2012. :)

FC

[Matthew Miller]

On Mon, Nov 07, 2016 at 07:30:54PM -0300, Fernando Cassia wrote:
> Fedora/RedHat's stance on btfs is "passive agressive" (Not Invented Here
> Syndrome).

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.
> Don't get me wrong, there are many things to like about RedHat/Fedora, but
> BTRFS support is not one of them.

While I definitely disagree with your characterization above, this I
do agree with.

[Andre Robatino]

> 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".

Why was it considered ready for OpenSUSE? Did they settle for using a stripped-down version (features disabled)?

[Gour]

Matthew Miller  writes:
> 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".

:-)
> While I definitely disagree with your characterization above, this I
> do agree with.

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

[Fernando Cassia]

On Mon, Nov 7, 2016 at 7:41 PM, Matthew Miller 
wrote:
> That's absolutely not true. Fedora has wanted to use Btfs since... one
> of the Boston FUDCons in 2008 or 2009

Well, we disagree.

FC

[Mark Haney]

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  wrote:
> On Mon, Nov 7, 2016 at 7:41 PM, Matthew Miller 
> wrote:
> > That's absolutely not true. Fedora has wanted to use Btfs since... one
> > of the Boston FUDCons in 2008 or 2009
>
> Well, we disagree.
> FC
>
> During times of Universal Deceit, telling the truth becomes a
> revolutionary act
> Durante épocas de Engaño Universal, decir la verdad se convierte en un
> Acto Revolucionario
> George Orwell
>
> users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Fernando Cassia]

On 11/8/16, Mark Haney  wrote:
> 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 /.

Name me one piece of software that is totally bug-free. H*ck, IBM's
JFS ate my data on OS/2 one day, on a "stable" piece of software.
Thanks to still-undiscovered APAR ...

http://comp.os.os2.bugs.narkive.com/ypcAmVsk/xr-c005-is-out
APAR=PJ29386 JFS_WRITE CAUSES TRAP 0003 DURING A DIRECTORY WRITE
APAR=PJ29609 EXCEPTION IN MODULE JFS - TRAP 0003 IN ***@4
ALSO FIXES SEVERAL HANG PROBLEMS
APAR=PJ29664 TRAP IN JFS FS32_OPENCREATE WHEN OPENING A FILE WITH
FILENAME THAT CONTAINS A WILDCARD.

JFS had its own share of issues on AIX, too
http://pages.citebite.com/u5o6e0o7trmi

That's what FUD is about, anyway. Repeat gossip in order to stop more
people to install a given piece of software, which in turn would have
helped to identify potential bugs and have them fixed faster. Aka "the
self-fulfilling prophecy".

But hey, Google must be full of dumb people...
https://www.youtube.com/watch?v=6DplcPrQjvA
http://marc.merlins.org/linux/talks/2015/Btrfs-LCA2015/Btrfs.pdf

Anyway... I've been told repeatedly that btrfs causes cpu overheating,
exhausts batteries and kills puppies.
FC

[Andras Simon]

2016-11-08 19:00 GMT+01:00, Fernando Cassia :
> Name me one piece of software that is totally bug-free. H*ck, IBM's
> JFS ate my data on OS/2 one day, on a "stable" piece of software.

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.

[Mark Haney]

Did I say ANYTHING about it being bug-free?  No.  Maybe you should read the
bloody post before you go spewing that diarrhea out of your mouth.

I said that BTRFS was NOT PRODUCTION READY.  (Is that big enough text for
you?)

I swear, these mailing lists are degenerating to the point of being nearly
useless.

However, if you don't want to take the Fedora/RH/CentOS engineer's word
that BTRFS isn't production ready and you barf a production system, don't
say you weren't warned.

On a side note, it's half-wit cretins like you that run people off Linux,
even now.  I'm sure you think trying the "I'm smarter than you" bullying
works on your friends, but that crap doesn't fly with me little man.

On Tue, Nov 8, 2016 at 1:00 PM, Fernando Cassia  wrote:
> On 11/8/16, Mark Haney  wrote:
> > 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 /.
>
> Name me one piece of software that is totally bug-free. H*ck, IBM's
> JFS ate my data on OS/2 one day, on a "stable" piece of software.
> Thanks to still-undiscovered APAR ...
>
> http://comp.os.os2.bugs.narkive.com/ypcAmVsk/xr-c005-is-out
> APAR=PJ29386 JFS_WRITE CAUSES TRAP 0003 DURING A DIRECTORY WRITE
> APAR=PJ29609 EXCEPTION IN MODULE JFS - TRAP 0003 IN ***@4
> ALSO FIXES SEVERAL HANG PROBLEMS
> APAR=PJ29664 TRAP IN JFS FS32_OPENCREATE WHEN OPENING A FILE WITH
> FILENAME THAT CONTAINS A WILDCARD.
>
> JFS had its own share of issues on AIX, too
> http://pages.citebite.com/u5o6e0o7trmi
>
> That's what FUD is about, anyway. Repeat gossip in order to stop more
> people to install a given piece of software, which in turn would have
> helped to identify potential bugs and have them fixed faster. Aka "the
> self-fulfilling prophecy".
>
> But hey, Google must be full of dumb people...
> https://www.youtube.com/watch?v=6DplcPrQjvA
> http://marc.merlins.org/linux/talks/2015/Btrfs-LCA2015/Btrfs.pdf
>
> Anyway... I've been told repeatedly that btrfs causes cpu overheating,
> exhausts batteries and kills puppies.
> FC
> _______________________________________________
> users mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]

[Matthew Miller]

On Tue, Nov 08, 2016 at 01:44:00PM -0500, Mark Haney wrote:
> Did I say ANYTHING about it being bug-free?  No.  Maybe you should read the
> bloody post before you go spewing that diarrhea out of your mouth.

Hey, maybe time to step back from the email a little bit. This isn't
an acceptable way to talk on Fedora mailing lists.

[Gour]

Matthew Miller  writes:
> Meanwhile RHEL (and Fedora Server) use XFS, which was *definitely* not
> invented at Red Hat or by Fedora.

I forgot to create bios_boot partition during my install and ended up
with MBR instead of GPT…so, did re-install and switched (back) to XFS.

Thank you, all, for your your input!

Sincerely,
Gour

[Chris Murphy]

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

[Gour]

Chris Murphy  writes:
> Some of this is a repeat, as this comes up from time to time.

[…]

Thank you for the input - I’m glad I did the right chocue with XFS for
my Raid1 setup. ;)

Sincerely,
Gour