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