Re: Discussion: what would not blocking on btrfs look like?

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

 



On Sat, 2019-08-24 at 07:31 -0700, Adam Williamson wrote:
> On Fri, 2019-08-23 at 19:00 -0600, 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?
> 
> Nothing. The kernel team's concern is not related to this bug or the
> handling of this bug in any way. The only relevance of the bug is
> that
> it alerted the kernel team to the fact that we currently block on
> btrfs, which they think we should not.

I understand them. The point is, for them and even us (the installer)
is work on BTRFS not a priority. It's something we can't benefit on
RHEL and it could be almost completely replaced by LVM + xfs solution.
However, it still giving us bugs and making our test surface bigger.

>From the Anaconda team PoV it would make our lives easier to not
support BTRFS at all. I'm not saying that we should drop BTRFS in
Fedora, only that it would be easier for Anaconda team to be without
that on Fedora.

> 
> > 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,
> 
> You're misunderstanding here. It's not the fact that a bug showed up
> which caused the concern.

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list



[Index of Archives]     [Kickstart]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]
  Powered by Linux