Re: [atomic-devel] Btrfs + overlayfs

[Chris Murphy <lists colorremedies com>]

On Fri, Jul 21, 2017 at 11:03 AM, Matthew Miller <mattdm mattdm org> wrote:
> On Fri, Jul 21, 2017 at 10:16:16AM -0600, Chris Murphy wrote:
>> This is a followup to this:
>> Figure out comprehensive strategy for atomic host container storage
>> https://pagure.io/atomic-wg/issue/281
>>
>> I said I'd post something to the Btrfs devel list about combining
>> Btrfs and overlayfs; and I got back a couple interesting replies
>> including, "We've been running Btrfs with Docker at appreciable scale
>> for a few months now (100-200k containers  / day )"
>
> Chris, my concern with Btrfs is over kernel engineering support. As you
> know, this has come up repeatedly on the Fedora devel list over the
> years and always the devs give the recommendation to not make it the
> default for anything — until basically we were asked to stop asking.

Seems outdated.

Insofar as I'm aware, it was based on resource limitations, and a very
reasonable concern about unknowns. The Btrfs regression tests were no
where near as mature or automated back then, there was massive code
churn with emphasis on feature inclusions rather than stabilization.
There's been at least a few solid years of emphasis on bug fixes. And
I'm not aware of any reason why Fedora's kernel team would be expected
to manage Btrfs patches any differently than ext4 or XFS, as in not at
all.

I'm immediately suspicious when "stop asking" becomes a habit.
Upstream Btrfs is not going to say "Here I am! I'm ready for you
Fedora!" They've made their position very clear, the cards are laid
out on the table, and projects can use it or not use it. They don't
send out engraved invitations to use it. So if "stop asking" is still
the position after all this time, that to me is absolutely clear
abandonment of Btrfs by Fedora, draw a line in the sand. Because there
is no way it spontaneously just happens out of thin air. Just saying
"we don't want to because we don't; why? because why" is a more
convincing answer to me than "don't ask" or "don't call us, we'll call
you" or "I think I'm busy that night".


> Meanwhile, I don't see Red Hat making large moves around Btrfs, while I
> *do* see significant investment in XFS, including some interesting new
> projects like Stratis *. I know I've been waiting for Btrfs since
> FUDCon Boston 2009, but at this point XFS really seems like it's the
> better choice for the forseeable future.

This doesn't solve any of the listed grievances today. Btrfs does, and
that code is done and tested for a long time. The additional code
needed, maybe it's going to get thrown away sooner than later, who
knows, but at least it won't be much code.

While lack of fs shrink is suboptimal it's not a showstopper for cloud
images. But I definitely see it as a showstopper for
workstation-ostree. Windows and macOS have online fs shrink support
for years. Fedora has offline ext4 shrink, and Btrfs would bring
online shrink. XFS is a clear regression in this area, and I do not
think Joe User will like that.

If you don't want to have all your eggs in one red basket, but still
prefer a more conservative approach, you could consider status quo for
cloud/atomic host installations; and just move workstation-ostree to
Btrfs. It's not that widely used yet, it's not a release blocking
image, and it's easily reversed. But it's more work to support both
things.


-- 
Chris Murphy