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
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
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
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
On Tue, Jun 23, 2020 at 6:40 PM Robin Laing MeSat@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
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 readonly, 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!
On Tue, Jun 23, 2020 at 3:56 PM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Jun 23, 2020 at 6:40 PM Robin Laing MeSat@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
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 readonly, 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
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
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.
On Tue, Jun 23, 2020 at 5:35 PM Chris Murphy chrismurphy@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
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
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
On 23/06/2020 16:55, Neal Gompa wrote:
On Tue, Jun 23, 2020 at 6:40 PM Robin Laing MeSat@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
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 readonly, 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
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@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
-- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ kde mailing list -- kde@lists.fedoraproject.org To unsubscribe send an email to kde-leave@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
On Tue, Jun 23, 2020 at 8:38 PM Pizza Dude pizzadudedotca@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.
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
On Wed, Jun 24, 2020 at 1:54 AM Mattia Verga mattia.verga@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).
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.
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
-
Chris Murphy -
Kai Bojens -
Mattia Verga -
Neal Gompa -
Patrick O'Callaghan -
Pizza Dude -
Robin Laing -
Troy Dawson