> 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. For users that run virtual machines, it sounds like they will need to set the "nodatacow" attribute for all vm images in order to get acceptable performance. If this isn't made clear I could imagine a lot of performance complaints from users. Also what can/should be done to help users that intend to run databases on Fedora? Does anyone know how openSUSE handles these use cases? _______________________________________________ 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
