On Wed, Jul 01, 2020 at 11:28:10AM +0100, Steven Whitehouse wrote:
Hi,
On 01/07/2020 07:54, Zbigniew Jędrzejewski-Szmek wrote:
>On Mon, Jun 29, 2020 at 03:15:23PM -0400, Solomon Peachy wrote:
>>So yes, I think an explicit "let's all test btrfs (as anaconda
>>configures it) before we make it default" period is warranted.
>>
>>Perhaps one can argue that Fedora has already been doing that for the
>>past two years (since 2018-or-later-btrfs is what everyone with positive
>>results appears to be talking about), but it's still not clear that
>>those deployments utilize the same feature set as Fedora's defaults, and
>>how broad the hardware sample is.
>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.
>
>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.
>
>Zbyszek
Indeed, it is an important point, and taking care is very important
when dealing with other people's data, which is in effect what we
are discussing here.
When we looked at btrfs support in RHEL, we took quite a long time
over it. In fact I'm not quite sure how long, since the process had
started before I was involved, but it was not a decision that was
made quickly, and a great deal of thought went into it. It was
difficult to get concrete information about the stability aspects at
the time. Just like the discussions that have taken place on this
thread, there was a lot of anecdotal evidence, but that is not
always a good indicator. Since time has passed since then, and there
is now more evidence, this part of the process should be easier.
That said to get a meaningful comparison then ideally one would want
to compare on the basis of user populations of similar size and
technical skill level, and look not just at the overall number of
bugs reported, but at the rate those bugs are being reported too.
Yeah. I have no doubt that the decision was made carefully back then.
That said, time has passed, and btrfs has evolved and our use cases
have evolved too, so a fresh look is good.
We have
https://fedoraproject.org/wiki/Changes/DNF_Better_Counting,
maybe this could be used to collect some statistics about the fs type
too.
It is often tricky to be sure of the root cause of bugs - just
because a filesystem reports an error doesn't mean that it is at
fault, it might be a hardware problem, or an issue with volume
management. Figuring out where the real problem lies is often very
time consuming work. Without that work though, the raw numbers of
bugs reported can be very misleading.
It would be worth taking that step here, and
asking each of the spins what are the features that they would most
like to see from the storage/fs stack. Comparing filesystems in the
abstract is a difficult task, and it is much easier against a
context. I know that some of the issues have already been discussed
in this thread, but maybe if someone was to gather up a list of
requirements from those messages then that would help to direct
further discussion,
Actually that part has been answered pretty comprehensively. The split
between / and /home is hurting users and we completely sidestep it
with this change. The change page lists a bunch of other benefits,
incl. better integration with the new resource allocation mechanisms
we have with cgroups2. So in a way this is a follow-up to the
cgroupsv2-by-default change in F31. Snapshots and subvolumes also give
additional powers to systemd-nspawn and other tools. I'd say that the
huge potential of btrfs is clear. It's the possibility of the loss of
stability that is my (and others') worry and the thing which is hard
to gauge.
Zbyszek