Re: User experience issue on btrfs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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.

Michael

_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux