On Fri, Jul 21, 2017 at 11:03 AM, Matthew Miller <mat...@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
