I like this approach, a lot. I'm all in favour of switching to btrfs
(I've been using it for a while, on server & desktop), and I think this
would be a safe approach to do so.
On 01.07.20 20:24, Matthew Miller wrote:
On Wed, Jul 01, 2020 at 06:54:02AM +0000, Zbigniew Jędrzejewski-Szmek
> Making btrfs opt-in for F33 and (assuming the result go well) opt-out for F34
> could be good option. I know technically it is already opt-in, but it's not
> very visible or popular. We could make the btrfs option more prominent and
> ask people to pick it if they are ready to handle potential fallout.
I'm leaning towards recommending this as well. I feel like we don't have
good data to make a decision on -- the work that Red Hat did previously when
making a decision was 1) years ago and 2) server-focused, and the Facebook
production usage is encouraging but also not the same use case. I'm
particularly concerned about metadata corruption fragility as noted in the
Usenix paper. (It'd be nice if we could do something about that!)
Given the number of Fedora desktop users, even an increase of 0.1% in
now-I-can't-boot situations would be a catastrophe. Is that a risk? I
literally don't know. Maybe it's not -- but we've worked hard to get Fedora
a reputation of being problem-free and something that leads without being
"bleeding edge". It's a tricky balance.
> Normally we just switch the default or we don't, without half measures. But
> the fs is important enough and complicated enough to be extra careful about
> any transitions.
Maybe we could add an "Automatically configure with btrfs (experimental)"
option to the Installation Destination screen, and then feature that in
Fedora Magazine and schedule a number of test days?
To be clear, I'm not suggesting this as a blocking tactic. The assumption
would be that we'd go ahead with flipping the defaults (as you say above)
for F34 unless the results come back in a way that gives us pause.