1:23 p.m.
Hey all,
Chris Murphy and I are working on a change to switch Fedora's desktop
variants to Btrfs[1]. The plan is for all Fedora desktop variants to
switch over, which means both release-blocking desktops
(Workstation/GNOME and KDE) will use Btrfs by default going forward. I
expect this to be a smooth change, as Btrfs has been a
release-blocking filesystem for many years now (at least since Fedora
20) and has had OpenQA tests to verify its functionality for nearly as
long as OpenQA has been in use in Fedora for testing. And I've
personally been using Btrfs on all my Fedora systems (~5 physical
machines and ~100 virtual machines) since 2015 with no issues.
My expectation is that there should be no work for the SIG to do
(beyond me doing the work, of course). For all the words that are in
the change proposal[1], the extent of the change is to flip the
settings in Anaconda to use Btrfs by default on new installations.
I'm interested in hearing about your feedback on the change proposal.
I am excited about this, personally, as I think there's some serious
opportunity to collaborate with KDE upstream and our friends at
openSUSE on taking advantage of Btrfs features to make a smoother
experience.
Thanks in advance and best regards,
Neal
[1]: https://fedoraproject.org/wiki/Changes/BtrfsByDefault
--
真実はいつも一つ！/ Always, there's only one truth!
4:01 p.m.
On Tue, 2020-06-23 at 14:23 -0400, Neal Gompa wrote:
Hey all,
Chris Murphy and I are working on a change to switch Fedora's desktop
variants to Btrfs[1]. The plan is for all Fedora desktop variants to
switch over, which means both release-blocking desktops
(Workstation/GNOME and KDE) will use Btrfs by default going forward. I
expect this to be a smooth change, as Btrfs has been a
release-blocking filesystem for many years now (at least since Fedora
20) and has had OpenQA tests to verify its functionality for nearly as
long as OpenQA has been in use in Fedora for testing. And I've
personally been using Btrfs on all my Fedora systems (~5 physical
machines and ~100 virtual machines) since 2015 with no issues.
My expectation is that there should be no work for the SIG to do
(beyond me doing the work, of course). For all the words that are in
the change proposal[1], the extent of the change is to flip the
settings in Anaconda to use Btrfs by default on new installations.
I'm interested in hearing about your feedback on the change proposal.
I am excited about this, personally, as I think there's some serious
opportunity to collaborate with KDE upstream and our friends at
openSUSE on taking advantage of Btrfs features to make a smoother
experience.
Sounds good to me. I've had /home on Btrfs for years with no issues,
though I don't do anything fancy with it. Getting rid of LVM would be a
big plus in my view (IIRC LVM has other features, but on a desktop I've
never seen the point).
poc
5:40 p.m.
On 23/06/2020 12:23, Neal Gompa wrote:
Hey all,
Chris Murphy and I are working on a change to switch Fedora's desktop
variants to Btrfs[1]. The plan is for all Fedora desktop variants to
switch over, which means both release-blocking desktops
(Workstation/GNOME and KDE) will use Btrfs by default going forward. I
expect this to be a smooth change, as Btrfs has been a
release-blocking filesystem for many years now (at least since Fedora
20) and has had OpenQA tests to verify its functionality for nearly as
long as OpenQA has been in use in Fedora for testing. And I've
personally been using Btrfs on all my Fedora systems (~5 physical
machines and ~100 virtual machines) since 2015 with no issues.
My expectation is that there should be no work for the SIG to do
(beyond me doing the work, of course). For all the words that are in
the change proposal[1], the extent of the change is to flip the
settings in Anaconda to use Btrfs by default on new installations.
I'm interested in hearing about your feedback on the change proposal.
I am excited about this, personally, as I think there's some serious
opportunity to collaborate with KDE upstream and our friends at
openSUSE on taking advantage of Btrfs features to make a smoother
experience.
Thanks in advance and best regards,
Neal
[1]: https://fedoraproject.org/wiki/Changes/BtrfsByDefault
I tried BTRFS on a system and was happy until I had a problem that
couldn't be fixed and it made remote backups impossible. Our system
admin and myself tried to fix it and every time ended up at the same
point that everything suggested was a full rebuild of the damaged file
system after a reformat.
Are all the tools there now to fix all file system faults other than a
failed drive?
I don't remember the details of the problem as it was a couple of years
ago. I personally will avoid BTRFS until I know that there are fsck
tools available.
While searching I am still seeing many comments from last month that end
with stuff like this.
***
My advice:
Do not use btrfsck
Do not try to fix the broken partition
Make a backup in the simplest way possible, e.g. with dd
As @SleeplessSloth said, its usually possible to mount it read
only, and create a new partition with the files.
https://github.com/maharmstone/btrfs/issues/215
***
Archlinux has a warning about using Btrfs.
https://wiki.archlinux.org/index.php/Btrfs
Warning: Btrfs has some features that are unstable. See the Btrfs Wiki's
Status, Is Btrfs stable? and Getting started for more detailed
information. See the #Known issues section.
***
But for me, this is the most telling.
https://btrfs.wiki.kernel.org/index.php/FAQ#Is_btrfs_stable.3F
Is btrfs stable?
Short answer: Maybe.
***
From the above links, until at least in the btrfs.wiki.kernel.org it
should be classified as "Stable" before being a default file system.
Just my thoughts
Some of the features in btrfs were the reason I tried it.
Robin
5:55 p.m.
On Tue, Jun 23, 2020 at 6:40 PM Robin Laing <MeSat(a)telusplanet.net> wrote:
On 23/06/2020 12:23, Neal Gompa wrote:
> Hey all,
>
> Chris Murphy and I are working on a change to switch Fedora's desktop
> variants to Btrfs[1]. The plan is for all Fedora desktop variants to
> switch over, which means both release-blocking desktops
> (Workstation/GNOME and KDE) will use Btrfs by default going forward. I
> expect this to be a smooth change, as Btrfs has been a
> release-blocking filesystem for many years now (at least since Fedora
> 20) and has had OpenQA tests to verify its functionality for nearly as
> long as OpenQA has been in use in Fedora for testing. And I've
> personally been using Btrfs on all my Fedora systems (~5 physical
> machines and ~100 virtual machines) since 2015 with no issues.
>
> My expectation is that there should be no work for the SIG to do
> (beyond me doing the work, of course). For all the words that are in
> the change proposal[1], the extent of the change is to flip the
> settings in Anaconda to use Btrfs by default on new installations.
>
> I'm interested in hearing about your feedback on the change proposal.
> I am excited about this, personally, as I think there's some serious
> opportunity to collaborate with KDE upstream and our friends at
> openSUSE on taking advantage of Btrfs features to make a smoother
> experience.
>
> Thanks in advance and best regards,
> Neal
>
> [1]: https://fedoraproject.org/wiki/Changes/BtrfsByDefault
>
I tried BTRFS on a system and was happy until I had a problem that
couldn't be fixed and it made remote backups impossible. Our system
admin and myself tried to fix it and every time ended up at the same
point that everything suggested was a full rebuild of the damaged file
system after a reformat.
Are all the tools there now to fix all file system faults other than a
failed drive?
In the last few kernel releases, there's been a lot of work to merge
the things people did manually to recover Btrfs filesystems into the
kernel to happen automatically. Btrfs is increasingly able to
self-heal in nearly all situations, provided that some kind of
hardware fault does not exist (e.g. bad drive, bad disk controller,
etc.).
I don't remember the details of the problem as it was a couple of
years
ago. I personally will avoid BTRFS until I know that there are fsck
tools available.
While searching I am still seeing many comments from last month that end
with stuff like this.
***
My advice:
Do not use btrfsck
Do not try to fix the broken partition
Make a backup in the simplest way possible, e.g. with dd
As @SleeplessSloth said, its usually possible to mount it read
only, and create a new partition with the files.
https://github.com/maharmstone/btrfs/issues/215
***
Archlinux has a warning about using Btrfs.
https://wiki.archlinux.org/index.php/Btrfs
Warning: Btrfs has some features that are unstable. See the Btrfs Wiki's
Status, Is Btrfs stable? and Getting started for more detailed
information. See the #Known issues section.
***
But for me, this is the most telling.
https://btrfs.wiki.kernel.org/index.php/FAQ#Is_btrfs_stable.3F
Is btrfs stable?
Short answer: Maybe.
***
From the above links, until at least in the btrfs.wiki.kernel.org it
should be classified as "Stable" before being a default file system.
Just my thoughts
Some of the features in btrfs were the reason I tried it.
The wiki definitely needs some improvement here. It's not uncommon for
the Btrfs wiki to get stale, and the wiki is locked down to prevent
spam attacks (it is, after all, kernel.org!).
It is true that btrfsck / btrfs check should be avoided in most
scenarios. This tool specifically aims to recover a Btrfs filesystem
at any cost, which is a very special case that should nearly never
happen. Btrfs' design also makes it so that you should not really need
this. The filesystem will automatically handle recovering in most
spurious error scenarios, as well as automatically restructure itself
to optimize for performance regularly.
There is also some more effort around providing more automatic failure
recovery features with a combination of systemd and btrfs-progs
enhancements for worst-case scenarios.
However, Btrfs *is* more sensitive to bad hardware than ext4/xfs, so
you may find that your hardware isn't as good as it purported to be,
due to the stronger integrity checking and greater sensitivity to
hardware-induced errors.
When we had Btrfs developers talk to us in the Workstation working
group meeting last week, they talked to us in-depth about these sorts
of things and gave us a good idea of how well it's worked for them at
scale (they have more instances of the filesystem in use in production
in their datacenters and their laptops than there are Fedora users in
total).
I'm reasonably confident that it'll do quite well for us, and I
believe that you shouldn't have to worry about situations like that
happening unless there's a hardware fault these days.
--
真実はいつも一つ！/ Always, there's only one truth!
6:43 p.m.
On Tue, Jun 23, 2020 at 3:56 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
On Tue, Jun 23, 2020 at 6:40 PM Robin Laing <MeSat(a)telusplanet.net> wrote:
>
> On 23/06/2020 12:23, Neal Gompa wrote:
> > Hey all,
> >
> > Chris Murphy and I are working on a change to switch Fedora's desktop
> > variants to Btrfs[1]. The plan is for all Fedora desktop variants to
> > switch over, which means both release-blocking desktops
> > (Workstation/GNOME and KDE) will use Btrfs by default going forward. I
> > expect this to be a smooth change, as Btrfs has been a
> > release-blocking filesystem for many years now (at least since Fedora
> > 20) and has had OpenQA tests to verify its functionality for nearly as
> > long as OpenQA has been in use in Fedora for testing. And I've
> > personally been using Btrfs on all my Fedora systems (~5 physical
> > machines and ~100 virtual machines) since 2015 with no issues.
> >
> > My expectation is that there should be no work for the SIG to do
> > (beyond me doing the work, of course). For all the words that are in
> > the change proposal[1], the extent of the change is to flip the
> > settings in Anaconda to use Btrfs by default on new installations.
> >
> > I'm interested in hearing about your feedback on the change proposal.
> > I am excited about this, personally, as I think there's some serious
> > opportunity to collaborate with KDE upstream and our friends at
> > openSUSE on taking advantage of Btrfs features to make a smoother
> > experience.
> >
> > Thanks in advance and best regards,
> > Neal
> >
> > [1]: https://fedoraproject.org/wiki/Changes/BtrfsByDefault
> >
>
>
> I tried BTRFS on a system and was happy until I had a problem that
> couldn't be fixed and it made remote backups impossible. Our system
> admin and myself tried to fix it and every time ended up at the same
> point that everything suggested was a full rebuild of the damaged file
> system after a reformat.
>
> Are all the tools there now to fix all file system faults other than a
> failed drive?
>
In the last few kernel releases, there's been a lot of work to merge
the things people did manually to recover Btrfs filesystems into the
kernel to happen automatically. Btrfs is increasingly able to
self-heal in nearly all situations, provided that some kind of
hardware fault does not exist (e.g. bad drive, bad disk controller,
etc.).
> I don't remember the details of the problem as it was a couple of years
> ago. I personally will avoid BTRFS until I know that there are fsck
> tools available.
>
> While searching I am still seeing many comments from last month that end
> with stuff like this.
>
> ***
>
> My advice:
>
> Do not use btrfsck
> Do not try to fix the broken partition
> Make a backup in the simplest way possible, e.g. with dd
> As @SleeplessSloth said, its usually possible to mount it read
> only, and create a new partition with the files.
>
> https://github.com/maharmstone/btrfs/issues/215
>
> ***
>
> Archlinux has a warning about using Btrfs.
> https://wiki.archlinux.org/index.php/Btrfs
> Warning: Btrfs has some features that are unstable. See the Btrfs Wiki's
> Status, Is Btrfs stable? and Getting started for more detailed
> information. See the #Known issues section.
>
> ***
>
> But for me, this is the most telling.
> https://btrfs.wiki.kernel.org/index.php/FAQ#Is_btrfs_stable.3F
>
> Is btrfs stable?
>
> Short answer: Maybe.
>
> ***
>
> From the above links, until at least in the btrfs.wiki.kernel.org it
> should be classified as "Stable" before being a default file system.
>
> Just my thoughts
>
> Some of the features in btrfs were the reason I tried it.
>
The wiki definitely needs some improvement here. It's not uncommon for
the Btrfs wiki to get stale, and the wiki is locked down to prevent
spam attacks (it is, after all, kernel.org!).
It is true that btrfsck / btrfs check should be avoided in most
scenarios. This tool specifically aims to recover a Btrfs filesystem
at any cost, which is a very special case that should nearly never
happen. Btrfs' design also makes it so that you should not really need
this. The filesystem will automatically handle recovering in most
spurious error scenarios, as well as automatically restructure itself
to optimize for performance regularly.
There is also some more effort around providing more automatic failure
recovery features with a combination of systemd and btrfs-progs
enhancements for worst-case scenarios.
However, Btrfs *is* more sensitive to bad hardware than ext4/xfs, so
you may find that your hardware isn't as good as it purported to be,
due to the stronger integrity checking and greater sensitivity to
hardware-induced errors.
When we had Btrfs developers talk to us in the Workstation working
group meeting last week, they talked to us in-depth about these sorts
of things and gave us a good idea of how well it's worked for them at
scale (they have more instances of the filesystem in use in production
in their datacenters and their laptops than there are Fedora users in
total).
I personally would throw out the datacenter numbers.
Why?
Through your whole email you keep saying "except for hardware failures"
Datacenters tend to have lifetimes. Meaning that if a machine/disk is
too old it get's replaced. Or at least put in the "when this dies it
get's replaced."
Datacenters are also much more uniform. If you 1000 machines, the
odds are that at most you have 10 to 20 variety of machines and/or
hard drives. One the datacenter I last worked at if you had 1000
machines, you had 1 variety.
What Fedora, and especially desktop Fedora, has is variety. Variety
on new, medium, and old machines.
How many people on this list often get hand-me down machines from
windows users and we throw Fedora on them and they work great.
Why do they work great?
Because most of those hardware errors, especially disk errors, are
recoverable or not even noticed.
I'm reasonably confident that it'll do quite well for us, and
I
believe that you shouldn't have to worry about situations like that
happening unless there's a hardware fault these days.
Did you count how many times you said "unless there's hardware
problems" in your email.
That does not give me confidence.
Troy
7:35 p.m.
On Tue, Jun 23, 2020 at 3:56 PM Neal Gompa
<ngompa13(a)gmail.com> wrote:
I personally would throw out the datacenter numbers.
The use case is different. But what they represent is sheer volume. No company is going to
put up with intrinsic problems with a file system at this scale. It's 100's of
thousands of btrfs instances, and millions of containers. If there were a per se problem,
it would be a shit show.
Consider openSUSE who have been using it for six years. And even in Fedora btrfs users at
slightly smaller scale is positive.
Why?
Through your whole email you keep saying "except for hardware failures"
Datacenters tend to have lifetimes. Meaning that if a machine/disk is
too old it get's replaced. Or at least put in the "when this dies it
get's replaced."
Datacenters are also much more uniform. If you 1000 machines, the
odds are that at most you have 10 to 20 variety of machines and/or
hard drives. One the datacenter I last worked at if you had 1000
machines, you had 1 variety.
Yes. Although they report using consumer hardware that they know is very ordinary if not
below average. Quite a lot of datacenters don't do that.
What Fedora, and especially desktop Fedora, has is variety. Variety
on new, medium, and old machines.
How many people on this list often get hand-me down machines from
windows users and we throw Fedora on them and they work great.
Why do they work great?
Because most of those hardware errors, especially disk errors, are
recoverable or not even noticed.
You've got two basic kinds: silent data corruption, and the case of unrecoverable read
(or write) error reported by the drive itself. The later should always result in an i/o
error, doesn't matter what the file system is. And there's no recovery for any
file system unless there's redundancy.
For silent data corruption, you don't actually know it's benign, you just know
it's getting to user space. What happens, depends on the corruption and the
application. It could result in a crash, or application confusion that leads to more
corruption, or maybe nothing. If it's your backup application, you're replicating
corruption into your backups silently.
It is correct that Fedora will have to assess the relative importance of catching such
corruptions early or letting them to do whatever it is that they do. Btrfs, upon detecting
data corruption, results in i/o error which should be properly handled by applications
anyway. And path to affected file is reported in kernel messages.
Did you count how many times you said "unless there's
hardware
problems" in your email.
That does not give me confidence.
In the hardware? Or the file system? Because just ignoring the reality of this class of
corruption is itself a choice that has consequences. And a significant consequence is, you
just don't know about it. How do you have confidence about events that you don't
know are occurring or what's happening as a result?
--
Chris Murphy
7:47 p.m.
I forgot to mention that while data corruption on btrfs results in i/o error, you can
still get your data out. Right now it's a bit unfun, by using an offline scrape tool.
And there may soon be a more tolerant run time mode that reports the errors but still
allows normal reads.
8:42 a.m.
On Tue, Jun 23, 2020 at 5:35 PM Chris Murphy
<chrismurphy(a)fedoraproject.org> wrote:
> On Tue, Jun 23, 2020 at 3:56 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
>
> I personally would throw out the datacenter numbers.
The use case is different. But what they represent is sheer volume. No company is going
to put up with intrinsic problems with a file system at this scale. It's 100's of
thousands of btrfs instances, and millions of containers. If there were a per se problem,
it would be a shit show.
Consider openSUSE who have been using it for six years. And even in Fedora btrfs users at
slightly smaller scale is positive.
> Why?
> Through your whole email you keep saying "except for hardware failures"
> Datacenters tend to have lifetimes. Meaning that if a machine/disk is
> too old it get's replaced. Or at least put in the "when this dies it
> get's replaced."
> Datacenters are also much more uniform. If you 1000 machines, the
> odds are that at most you have 10 to 20 variety of machines and/or
> hard drives. One the datacenter I last worked at if you had 1000
> machines, you had 1 variety.
Yes. Although they report using consumer hardware that they know is very ordinary if not
below average. Quite a lot of datacenters don't do that.
> What Fedora, and especially desktop Fedora, has is variety. Variety
> on new, medium, and old machines.
> How many people on this list often get hand-me down machines from
> windows users and we throw Fedora on them and they work great.
> Why do they work great?
> Because most of those hardware errors, especially disk errors, are
> recoverable or not even noticed.
You've got two basic kinds: silent data corruption, and the case of unrecoverable
read (or write) error reported by the drive itself. The later should always result in an
i/o error, doesn't matter what the file system is. And there's no recovery for any
file system unless there's redundancy.
For silent data corruption, you don't actually know it's benign, you just know
it's getting to user space. What happens, depends on the corruption and the
application. It could result in a crash, or application confusion that leads to more
corruption, or maybe nothing. If it's your backup application, you're replicating
corruption into your backups silently.
It is correct that Fedora will have to assess the relative importance of catching such
corruptions early or letting them to do whatever it is that they do. Btrfs, upon detecting
data corruption, results in i/o error which should be properly handled by applications
anyway. And path to affected file is reported in kernel messages.
> Did you count how many times you said "unless there's hardware
> problems" in your email.
> That does not give me confidence.
In the hardware? Or the file system? Because just ignoring the reality of this class of
corruption is itself a choice that has consequences. And a significant consequence is, you
just don't know about it. How do you have confidence about events that you don't
know are occurring or what's happening as a result?
Thank you for the clarifications and explanations. That helped calm me down.
I will admit, I'm still nervous, and will try it out on machines I can
easily wipe clean again. But I did that when XFS was becoming default
as well.
I still hope that someone will talk to whomever the right person is to
get btrfs back into RHEL.
Troy
10:58 a.m.
Thank you for the clarifications and explanations. That helped calm
me down.
I will admit, I'm still nervous, and will try it out on machines I can
easily wipe clean again. But I did that when XFS was becoming default
as well.
Josef, one of the btrfs maintainers helping out with this change, considers ext4, xfs, and
btrfs in the same realm of reliability. That is in normal operation.
And you're right to wonder: well what if it's not normal? What does the fallout
look like? Is it more fragile? We're used to a particular pattern with ext4, and that
pattern will change with btrfs. But I expect these details will come up in the inevitable
devel@ fireside chit chat. If someone doesn't ask, you should.
We'll also have to document the differences and recommendations, should the change
happen (this isn't a certainty, the community will have to want the change, and help
bring it about - whether one person or a dozen listed on a change proposal - it's not
enough to make it successful).
Mainly the idea of this preview of the change proposal is if folks familiar with btrfs in
KDE have some benefits/concerns stories that are KDE specific.
I still hope that someone will talk to whomever the right person is
to
get btrfs back into RHEL.
Yeah I can't really speak to that because I don't know anything about it. My focus
is on what's best for the Fedora community as a whole. And in this thread, what's
best for KDE users specifically, because likely there's some benefits/concerns that
are KDE specific that I haven't thought of.
--
Chris Murphy
4:10 p.m.
On Wed, 2020-06-24 at 15:58 +0000, Chris Murphy wrote:
Mainly the idea of this preview of the change proposal is if folks
familiar with btrfs in KDE have some benefits/concerns stories that are KDE specific.
I did wonder why this is being discussed on the KDE list rather than
Fedora Users. The original question doesn't seem to have anything
particular to do with KDE as such.
poc
12:04 a.m.
On 23/06/2020 16:55, Neal Gompa wrote:
On Tue, Jun 23, 2020 at 6:40 PM Robin Laing
<MeSat(a)telusplanet.net> wrote:
>
> On 23/06/2020 12:23, Neal Gompa wrote:
>> Hey all,
>>
>> Chris Murphy and I are working on a change to switch Fedora's desktop
>> variants to Btrfs[1]. The plan is for all Fedora desktop variants to
>> switch over, which means both release-blocking desktops
>> (Workstation/GNOME and KDE) will use Btrfs by default going forward. I
>> expect this to be a smooth change, as Btrfs has been a
>> release-blocking filesystem for many years now (at least since Fedora
>> 20) and has had OpenQA tests to verify its functionality for nearly as
>> long as OpenQA has been in use in Fedora for testing. And I've
>> personally been using Btrfs on all my Fedora systems (~5 physical
>> machines and ~100 virtual machines) since 2015 with no issues.
>>
>> My expectation is that there should be no work for the SIG to do
>> (beyond me doing the work, of course). For all the words that are in
>> the change proposal[1], the extent of the change is to flip the
>> settings in Anaconda to use Btrfs by default on new installations.
>>
>> I'm interested in hearing about your feedback on the change proposal.
>> I am excited about this, personally, as I think there's some serious
>> opportunity to collaborate with KDE upstream and our friends at
>> openSUSE on taking advantage of Btrfs features to make a smoother
>> experience.
>>
>> Thanks in advance and best regards,
>> Neal
>>
>> [1]: https://fedoraproject.org/wiki/Changes/BtrfsByDefault
>>
>
>
> I tried BTRFS on a system and was happy until I had a problem that
> couldn't be fixed and it made remote backups impossible. Our system
> admin and myself tried to fix it and every time ended up at the same
> point that everything suggested was a full rebuild of the damaged file
> system after a reformat.
>
> Are all the tools there now to fix all file system faults other than a
> failed drive?
>
In the last few kernel releases, there's been a lot of work to merge
the things people did manually to recover Btrfs filesystems into the
kernel to happen automatically. Btrfs is increasingly able to
self-heal in nearly all situations, provided that some kind of
hardware fault does not exist (e.g. bad drive, bad disk controller,
etc.).
> I don't remember the details of the problem as it was a couple of years
> ago. I personally will avoid BTRFS until I know that there are fsck
> tools available.
>
> While searching I am still seeing many comments from last month that end
> with stuff like this.
>
> ***
>
> My advice:
>
> Do not use btrfsck
> Do not try to fix the broken partition
> Make a backup in the simplest way possible, e.g. with dd
> As @SleeplessSloth said, its usually possible to mount it read
> only, and create a new partition with the files.
>
> https://github.com/maharmstone/btrfs/issues/215
>
> ***
>
> Archlinux has a warning about using Btrfs.
> https://wiki.archlinux.org/index.php/Btrfs
> Warning: Btrfs has some features that are unstable. See the Btrfs Wiki's
> Status, Is Btrfs stable? and Getting started for more detailed
> information. See the #Known issues section.
>
> ***
>
> But for me, this is the most telling.
> https://btrfs.wiki.kernel.org/index.php/FAQ#Is_btrfs_stable.3F
>
> Is btrfs stable?
>
> Short answer: Maybe.
>
> ***
>
> From the above links, until at least in the btrfs.wiki.kernel.org it
> should be classified as "Stable" before being a default file system.
>
> Just my thoughts
>
> Some of the features in btrfs were the reason I tried it.
>
The wiki definitely needs some improvement here. It's not uncommon for
the Btrfs wiki to get stale, and the wiki is locked down to prevent
spam attacks (it is, after all, kernel.org!).
It is true that btrfsck / btrfs check should be avoided in most
scenarios. This tool specifically aims to recover a Btrfs filesystem
at any cost, which is a very special case that should nearly never
happen. Btrfs' design also makes it so that you should not really need
this. The filesystem will automatically handle recovering in most
spurious error scenarios, as well as automatically restructure itself
to optimize for performance regularly.
There is also some more effort around providing more automatic failure
recovery features with a combination of systemd and btrfs-progs
enhancements for worst-case scenarios.
However, Btrfs *is* more sensitive to bad hardware than ext4/xfs, so
you may find that your hardware isn't as good as it purported to be,
due to the stronger integrity checking and greater sensitivity to
hardware-induced errors.
When we had Btrfs developers talk to us in the Workstation working
group meeting last week, they talked to us in-depth about these sorts
of things and gave us a good idea of how well it's worked for them at
scale (they have more instances of the filesystem in use in production
in their datacenters and their laptops than there are Fedora users in
total).
I'm reasonably confident that it'll do quite well for us, and I
believe that you shouldn't have to worry about situations like that
happening unless there's a hardware fault these days.
--
真実はいつも一つ！/ Always, there's only one truth!
Interesting comments and as others have said, I wouldn't use data center
systems for a good reference.
My machine was an older machine and there were no hardware issues that I
know of and it is a few years later on the same machine. HDD's are both
good. Machine is on a UPS.
As others have said in this thread, Fedora users don't want to spend
hours trying to diagnose and fix a file that won't delete because of
something within the file system. I didn't like it when everything I
read said I had to re-install my system.
I am trying to trace down two weird bugs in KDE that is frustrating
enough. Try doing it when you don't have all the time necessary to
trace it down.
For Fedora users, it should be safe enough that if something happens to
force you to do a cold, pull the plug shutdown, it should be easy to
recover with easy to use tools, preferable automatic on reboot. I admit
that I cannot remember the last time I have had to do that.
Before Btrfs is accepted as the default, there needs to be much testing
with pulling the plug on running machines and getting them up and
running in less than a few hours of work. Not Data Center machines.
Typical home, low power or high power machines.
Even though Fedora is a "testing" platform, it has to be reliable and if
the file system isn't reliable, then it will lose more users.
My reference for ease of use is my wife and daughter. If they cannot
maintain their machines with minimal help, then there is a problem with
the O/S. Presently, KDE on these machines is running much better than
Windows on my son's computer (he is a gamer).
If the wiki is out of date and the data is wrong, that doesn't help the
discussion either.
Robin
7:38 p.m.
Please clarify this:
Will BTRFS be optional? Meaning, in the installer, will I still be able to install Fedora
as ext4?
On June 23, 2020 2:23:55 p.m. EDT, Neal Gompa <ngompa13(a)gmail.com> wrote:
Hey all,
Chris Murphy and I are working on a change to switch Fedora's desktop
variants to Btrfs[1]. The plan is for all Fedora desktop variants to
switch over, which means both release-blocking desktops
(Workstation/GNOME and KDE) will use Btrfs by default going forward. I
expect this to be a smooth change, as Btrfs has been a
release-blocking filesystem for many years now (at least since Fedora
20) and has had OpenQA tests to verify its functionality for nearly as
long as OpenQA has been in use in Fedora for testing. And I've
personally been using Btrfs on all my Fedora systems (~5 physical
machines and ~100 virtual machines) since 2015 with no issues.
My expectation is that there should be no work for the SIG to do
(beyond me doing the work, of course). For all the words that are in
the change proposal[1], the extent of the change is to flip the
settings in Anaconda to use Btrfs by default on new installations.
I'm interested in hearing about your feedback on the change proposal.
I am excited about this, personally, as I think there's some serious
opportunity to collaborate with KDE upstream and our friends at
openSUSE on taking advantage of Btrfs features to make a smoother
experience.
Thanks in advance and best regards,
Neal
[1]: https://fedoraproject.org/wiki/Changes/BtrfsByDefault
--
真実はいつも一つ！/ Always, there's only one truth!
_______________________________________________
kde mailing list -- kde(a)lists.fedoraproject.org
To unsubscribe send an email to kde-leave(a)lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/kde@lists.fedoraproject.org
--
Sent from my Android device with K-9 Mail.
7:58 p.m.
On Tue, Jun 23, 2020 at 8:38 PM Pizza Dude <pizzadudedotca(a)gmail.com> wrote:
Please clarify this:
Will BTRFS be optional? Meaning, in the installer, will I still be able to install Fedora
as ext4?
Yes, you may select at install-time a different setup if you wish.
--
真実はいつも一つ！/ Always, there's only one truth!
12:52 a.m.
Il 23/06/20 20:23, Neal Gompa ha scritto:
Hey all,
...
Have BTRFS performances increased to a decent level? Last time I checked
they were terrible compared to EXT4 and looking at some phoronix
articles dated 2019 they still are.
I had adopted BTRFS when it was firstly introduced in Fedora and then
switched back to EXT4 some years ago when I read some articles that
claimed "btrfs is dead"... (for example
https://www.qnap.com/solution/qnap-ext4/en-us/ claims "Red Hat stops
using btrfs"...)
Mattia
8:54 a.m.
On Wed, Jun 24, 2020 at 1:54 AM Mattia Verga
<mattia.verga(a)protonmail.com> wrote:
Il 23/06/20 20:23, Neal Gompa ha scritto:
> Hey all,
>
> ...
Have BTRFS performances increased to a decent level? Last time I checked
they were terrible compared to EXT4 and looking at some phoronix
articles dated 2019 they still are.
Throughput on average has climbed to levels similar to ext4, and
depending on the setup may reach xfs levels or higher. Latency (time
to start doing I/O operations) is still sluggish in benchmarks, but
that is improving as well.
My personal experience is that desktop and developer workloads should
not have issues. In fact, performance may improve significantly if
transparent compression with zstd is turned on. And there's further
benefits if you're on SSD media.
I had adopted BTRFS when it was firstly introduced in Fedora and
then
switched back to EXT4 some years ago when I read some articles that
claimed "btrfs is dead"... (for example
https://www.qnap.com/solution/qnap-ext4/en-us/ claims "Red Hat stops
using btrfs"...)
I don't think QNAP actually understands how the storage works? Their
reasoning makes no sense.
With regard to snapshots, you can put those anywhere, including
another disk. It is true that making a snapshot will store it on the
same volume, but it also takes up no additional space to do that, and
you can send it to an offsite location trivially with "btrfs send".
As far as block based data transfer goes, "btrfs send" is an efficient
extent/block delta transfer of what's on the source volume vs the
destination volume. It's probably one of the most efficient ways to
backup a disk. And you can do "btrfs receive" to another computer over
a network of a send stream.
Red Hat stopped shipping Btrfs because they had no people to support
the tech preview anymore. I don't work for Red Hat, so I don't know
what they'll do in the future. But from my point of view, I don't
think they'd change anything unless we did it in Fedora first anyway.
Btrfs is heavily used by several companies: Facebook, Oracle, SUSE,
and Synology are the main ones I'm aware of (in terms of seeing
contributions to the kernel and offering products/services using
Btrfs).
--
真実はいつも一つ！/ Always, there's only one truth!
1:13 p.m.
Am 2020-06-23 20:23, schrieb Neal Gompa:
I'm interested in hearing about your feedback on the change
proposal.
I am excited about this, personally, as I think there's some serious
opportunity to collaborate with KDE upstream and our friends at
openSUSE on taking advantage of Btrfs features to make a smoother
experience.
Please don't. I've been using btrfs for several years now and really
like how it has developed and would recommend it to users who know what
they are doing. The problem I have with this proposal is at times when
btrfs breaks and you have to search the btrfs mailing lists for
solutions and have to ask some developers to do some wild stuff to get
it running again. You simply don't want to tell users that they have to
rebuild the extent tree or things like this. That's what happened to me
when btrfs introduced a new extent tree checker(?) in 5.4 (IIRC) – _I_
can fix stuff like this, beginners may not be able to do so.
4:30 p.m.
The goal of btrfs is to not become inconsistent in the first place, and the reason why it
can happen is pretty much always some kind of hardware problem. If there's extent tree
corruption on any file system, beginners will have difficulty. The btrfs repair experience
could be more involved than ext4, because with ext4 either the fsck works or it
doesn't. Whereas with btrfs there are more opportunities for both failure and recovery
due to the nature of copy-on-write and the fact everything including data is checksummed.
This won't be a common occurrence, but it's valid to wonder what this experience
will look like, and ensure the Fedora user to user community is ready.
--
Chris Murphy
1409
days inactive
1412
days old
16 comments
8 participants
participants (8)
-
Chris Murphy -
Kai Bojens -
Mattia Verga -
Neal Gompa -
Patrick O'Callaghan -
Pizza Dude -
Robin Laing -
Troy Dawson