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.
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,
Steve.
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
