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 _______________________________________________ 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
