On Sun, Jun 28, 2020 at 9:07 PM Michael Catanzaro <mcatanzaro@xxxxxxxxx> wrote: > > On Sun, Jun 28, 2020 at 3:40 pm, Chris Murphy <lists@xxxxxxxxxxxxxxxxx> > wrote: > > And yeah, how would anyone know all of this? And is it an opportunity > > for docs (probably) or desktop integration? Detect this workload or > > ask the user? I'm not sure. > > I'd like to propose a few guidelines: > > 1. If btrfs causes noticeable performance issues for users, that's not > OK. It's understood and expected that it might be slower at many > workloads, but if the difference is large enough that users notice a > significant regression in desktop responsiveness, that's a serious > problem. (I have no doubt the change owners believe such cases are very > rare, as otherwise btrfs would surely not be under consideration at > all.) > > 2. Exception to above rule: applications are expected to be suitably > optimized for the operating system, not vice-versa. So if a > virtualization framework or database is not using the recommended > chattr +C, that's the fault of the application, not Fedora, and it's OK > for writes to be slow while the application is busy pounding the disk. > Applications will not be updated for btrfs until after distros start > using it by default, so we cannot reasonably wait for applications on > this, as we'd wind up waiting another decade probably. Sounds like this > is easy for applications to fix, at least. > > 3. Users should not be expected to customize anything or use the > command line, ever, period. So for the purposes of figuring out what's > causing this performance issue, it sounds very useful to test different > mount options. But an actual solution must not require any > customization. > > Now, if I understand correctly, your theory (Chris) is that Alexandre's > performance issue would not have occurred if the discard=async mount > option were in use, and this mount option is planned to become default > before F33 anyway, so in theory the problem is likely already fixed. > So... OK. That timing is a bit awkward, but if that's indeed what's > going on, and that's the only problem we're aware of, it doesn't seem > like a terrible problem for this change proposal. > Yeah, I think this is a very fair thing. For what it's worth, I absolutely want usage of Btrfs to be as transparent as possible, so these are good guidelines for us to work with. > BTW Alexandre, I want to thank you for bringing your concerns to this > list, for following up with Chris's requests for more information and > further investigation, and for your interest in making sure Fedora > remains excellent by default. Although I have confidence in the change > owners' assessment of btrfs's stability and readiness, your experience > is very concerning and I hope we can get to the bottom of what went > wrong in your case. > Likewise, as one of the change owners driving this through, I want to thank you for earnestly trying it and giving us valuable feedback. My goal with this change is to make Fedora better and give us the foundation to do some amazing things in the near future. But I want us to have a solid baseline as well, and it's important to me (as well as all the change owners) that we have that. I am very confident that we can make this work for Fedora 33 and have a fantastic experience using Btrfs as the default filesystem, especially with folks like you and others giving us valuable feedback and information to help us make this even better. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
