On 8/23/19 9:00 PM, Chris Murphy wrote:
On Fri, Aug 23, 2019 at 1:17 PM Adam Williamson
<adamwill@xxxxxxxxxxxxxxxxx> wrote:
So, there was recently a Thing where btrfs installs were broken, and
this got accepted as a release blocker:
https://bugzilla.redhat.com/show_bug.cgi?id=1733388
Summary: This bug was introduced and discovered in linux-next, it
started to affect Fedora 5.3.0-rc0 kernels in openqa tests, patch
appeared during rc1, and the patch was merged into 5.3.0-rc2. The bug
resulted in a somewhat transient deadlock which caused installs to
hang, but no corruption. The fix, 2 files changed, 12 insertions, 8
deletions (1/2 the insertions are comments).
How remarkable or interesting is this bug? And in particular, exactly
how much faster should it have been fixed in order to avoid worrying
about it being a blocker bug?
7/25 14:27 utc bug patch was submitted to linux-btrfs@
7/25 22:33 utc bug was first reported in Fedora bugzilla
7/26 19:20 utc I confirmed upstream's patch related to this bug with
upstream and updated the Fedora bug
7/26 22:50 utc I confirmed it was merged into rc2, and updated the Fedora bug
So in the context of status quo, where Btrfs is presented as an option
in the installer and if there are bugs they Beta blocking, how could
or should this have been fixed sooner? What about the handling should
have been different?
That's a fair question. This bug actually represents how this _should_
work. The concern is that in the past we haven't seen a lot engagement
in the past. Maybe today that has changed as demonstrated by this thread.
I'm still concerned about having this be a blocker vs. just keeping it
as an option, simply because a blocker stops the entire release and it
can be a last minute scramble to get things fixed. This was the ideal
case for a blocker bugs and I'm skeptical about all bugs going this well.
If we had a few more people who were willing to be on the btrfs alias and
do the work for blocker bugs it would be a much stronger case.
I note here that ext2 and ext3 are offered as file systems in
Custom/Advanced partitioning and in this sense have parity with Btrfs.
If this same bug occurred in ext2 or ext3 would or should that cause
discussion to drop them from the installer, even if the bug were fixed
within 24 hours of discovery and patch? What about vfat? That's
literally the only truly required filesystem that must work, for the
most commonly supported hardware so it can't be dropped, we'd just be
stuck until it got fixed. That work would have to be done upstream,
yes?
I don't think that's really a fair comparison. Just because options
are presented doesn't mean all of them are equal. ext2/ext3 and vfat
have been in development for much longer than btrfs and length of development
is something that's particularly important for file system stability
from talking with file system developers. It's not impossible for there
to be bugs in ext4 for example (we've certainly seen them before) but
btrfs is only now gaining overall stability and we're still more likely to see
bugs, especially with custom setups where people are likely to find
edge cases.
Thanks,
Laura
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
