On Sat, Jun 27, 2020 at 3:12 AM Markus Larsson <qrsb...@uidzero.se> wrote:

> There's a difference between "can" and "should". I find this "<other guy> can 
> do this are you less of a man than <other guy>" tiresome.

Yes, I also find it tiresome when people make grandiose claims of
having facts on their side, and yet provide none, but inject hyperbole
into the conversation instead.

> When SLES made the switch they did only recommend it for system data not 
> production data because it kept breaking and data loss is painful.
> That was still the case 3 years ago, if they have reconsidered it has been 
> done later than that.
> It's very clear from both the openSUSE and the Arch community that btrfs has 
> higher failure rates than ext4 and the rate of catastrophic failure is 
> non-negligible.

Excellent! Provide the data. I'm looking forward to seeing this very
clear data. You can provide it, today?

I'm not using Btrfs because Facebook does or SUSE does. I'm using it
because I trust it, I value my data, I value the contents of my wallet
(money), and I'm saving time overall in my myriad use of it for work
and for testing Fedora. I've seen btrfs catch corruption other file
systems aren't designed to, however rare these are at an individual
level. Every day I benefit from compression, reflink copies and
snapshots, however incremental that benefit. And yet, I mostly
interact with it just like any other file system. It is an
exceptionally ordinary experience most of the time.

> To push for btrfs is doing a disservice to the new users and the not yet 
> competent.

This is not at all persuasive.

-- 
Chris Murphy
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org

Reply via email to