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.

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.

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 is also worth noting that when we made the decision for RHEL it was not just a question of stability, although that is obviously an important consideration. We looked at a wide range of factors, including the overall design and features. We had reached out to a number of potential users and asked them what features they wanted from their filesystems and tried to understand where we had gaps in our existing offerings. 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,


devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 

Reply via email to