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

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


On Wed, Aug 28, 2019 at 1:07 PM Josef Bacik <josef@xxxxxxxxxxxxxx> wrote:
> On Wed, Aug 28, 2019 at 03:01:16PM -0400, Josh Boyer wrote:
> > Fedora chugs along at the rate of daily upstream Linus snapshots.  If
> > you're hitting and fixing issues before Fedora users see them, I'm
> > curious why Fedora users would ever see them.
> >
> > Where does the lag come from?  Are the fixes queued internally?
> > Staged in an upstream subsystem tree?  Is there a way for interested
> > btrfs people to proactively just get those fixed in Fedora before
> > users hit them?
> For this particular example we saw the problem in testing and had a patch on the
> mailinglist before you hit the problem.  It was in a tree and sent to Linus, and
> was merged the day after the bugzilla was reported.  So yes before users see
> them, unless they are subscribed to the daily snapshots, which I assume is just
> for testing right?  Or were you guys going to ship 5.3-rc0?
> On one hand I understand all of the consternation around making btrfs bugs
> blockers for Fedora, but on the other hand it seems a bit silly to be having
> this conversation at all based on hitting a bug that went into the merge window
> and then was fixed before rc1 was even cut.  Thanks,

It is silly, if it's really safe to say that Btrfs won't be the
default file system in any release blocking deliverable. Having
blocker status was always a means to that end. But right now it's
maybe three (?) automated tests that depend on Btrfs working. If
Fedora Workstation defaulted to Btrfs, that's dozens or even hundreds
of tests? Adam?

Bug fix was merged in rc2. The patch on linux-btrfs@

25 Jul 2019 11:27:29 +0300 which is just before
kernel-5.3.0-0.rc1.git3.1.fc31, 2019-07-25 21:01:20

Plausibly it was in all rc0 and rc1 kernels. What if this deadlock
were happening in ext4 for all rc0 and rc1 kernels? What questions get
asked? How did the bug not get caught by xfstests before it got into
linux-next? Does anyone pop a gasket on lkml? Is this just a weird
sometimes it happens rarely kind of thing?

I don't know the exact nature of the bug, which goes to the kernel
team's point that someone who does know needs to tell them the autopsy
summary so they can really assess the default fs question.

And another question for QA. If it were Btrfs by default for
Workstation, would you just convert all the tests that rely only on
ext4 now to Btrfs? Or duplicate those tests so you can run them in
parallel? How much more testing is that and what's the impact on time
and resources?

Chris Murphy

Anaconda-devel-list mailing 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