Re: Fedora 33 System-Wide Change proposal: Make btrfs the default file system for desktop variants

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Jun 29, 2020 at 10:26:37AM -0600, Chris Murphy wrote:
> You've got an example where 'btrfs restore' saw no files at all? And
> you think it's the file system rather than the hardware, why?

Because the system failed to boot up, and even after offline repair 
attempts was still missing a sufficiently large chunk of the root 
filesystem to necessitate re-installation.

Because the same hardware provided literally years of problem-free 
stability with ext4 (before) and xfs (after).

> I think this is the wrong metaphor because it suggests btrfs caused
> the crapping. The sequence is: btrfs does the right thing, drive
> firmware craps itself and there's a power failure or a crash. Btrfs in
> the ordinary case doesn't care and boots without complaint. In the far

The first time, I needed to physically move the system, so the machine 
was shut down via 'shutdown -h now' on a console, and didn't come back 
up.

The second time was a routine post-dnf-update 'reboot', without power 
cycling anything.

At no point was there ever any unclean shutdown, and at the time of 
those reboots, no errors were reported in the kernel logs.

Once is a fluke, twice is a trend... and I didn't have the patience for 
a third try because I needed to be able to rely on the system to not eat 
itself.

I can't get the complete details at the moment, but it was an AMD E-350 
system with an 32GB ADATA SATA, configured using anaconda's btrfs 
defaults and only about 30% of disk space used.  Pretty minimal I/O.

I will concede that it's possible there was/is some sort 
hardware/firmware bug, but if so, only btrfs seemed to trigger it.

(more on this later)

> Come on. It's cleanly unmounted and doesn't mount?

Yes.  (See above)

(Granted, I'm using "mount" to mean "successfully mounted a writable 
 filesystem with data largely intact" -- I'm a bit fuzzy on the exact 
 details but I believe the it did mount read-only before the boot 
 crapped out due to missing/inaccessable system libraries.  I had to 
 resort to a USB stick to attempt repairs that were only partially 
 successful)

> All file systems have write ordering expectations. If the hardware
> doesn't honor that, it's trouble if there's a crash. What you're
> describing is 100% a hardware crapped itself case. You said it cleanly
> unmounted i.e. the exact correct write ordering did happen. And yet
> the file system can't be mounted again. That's a hardware failure.

That may be the case, but when there were no crashes, and neither ext4 
nor xfs crapped themselves under day-to-day operation with the same 
hardware, it's reasonable to infer that the problem has _something_ to 
do with the variable that changed, ie btrfs.

> There is no way for one person to determine if Btrfs is ready. That's
> done by combination of synthetic tests (xfstests) and volume
> regression testing on actual workloads. And by the way the Red Hat CKI
> project is going to help run btrfs xfstests for Fedora kernels.

Of course not, but the Fedora commnuity is made up of innumerable "one 
persons" each responsible for several special snowflake systems.

Let's say for sake of argument that my bad btrfs experiences were due to 
bugs in device firmware with btrfs's completely-legal usage patterns 
rather than bugs in btrfs-from-five-years-ago.  That's great... except 
my system still got trashed to the point of needing to be reinstalled, 
and finger-pointing can't bring back lost data.

How many more special snowflake drives are out there?  Think about how 
long it took Fedora to enable TRIM out of concern for potential data 
loss.  Why should this be any different?

(We're always going to be stuck with buggy firmware.  FFS, the Samsung 
 860 EVO SATA SSD that I have in my main workstation will hiccup to the 
 point of trashing data when used with AMD SATA controllers... even 
 under Windows!  Their official support answer is "Use an Intel 
 controller".  And that's a tier-one manufacturer who presumably has 
 among the best QA and support in the industry..)

If there is device/firmware known to be problematic, we need to keep 
track of these buggy devices and either automatically provide 
workarounds or some way to tell the user that proceeding with btrfs may 
be perilous to their data.

(Or perhaps the issues I had were due to bugs in btrfs-of-five-years-ago 
 that have long since been fixed.  Either way, given my twice-burned 
 experiences, I would want to verify that for myself before I entrust it 
 with any data I care about...)

> The questions are whether the Fedora community wants and is ready for
> Btrfs by default.

There are obviously some folks here (myself included) that have had very 
negative btrfs experiences.  Similarly, there are folks that have 
successfully overseen large-scale deployements of btrfs in their managed 
enviroments (not on Fedora though, IIUC)

So yes, I think an explicit "let's all test btrfs (as anaconda 
configures it) before we make it default" period is warranted.  

Perhaps one can argue that Fedora has already been doing that for the 
past two years (since 2018-or-later-btrfs is what everyone with positive 
results appears to be talking about), but it's still not clear that 
those deployments utilize the same feature set as Fedora's defaults, and 
how broad the hardware sample is.

 - Solomon
-- 
Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
                                      @pizza:shaftnet dot org   (matrix)
High Springs, FL                      speachy (freenode)

Attachment: signature.asc
Description: PGP signature

_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux