On Sun, Jun 28, 2020 at 7:09 PM Michael Catanzaro <mcatanzaro@xxxxxxxxx> wrote: > 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. Most cases are OK with the current defaults. Some narrow cases are optimized for the file systems that overwrite in place (ext4 xfs) which if they hammer on fsync aggressively isn't great for the file systems that are cow (btrfs zfs) or that are log (f2fs nilsfs). What specific optimizations apps should use depends on the problem. I don't want to give the impression that nodatacow (chattr +C) is what apps should be doing "to be fast on btrfs". It might be that they can reduce their fsync footprint. Or the problem might be lock contention related, and an easy optimization for a heavy metadata writing apps would be for this app to create+use their own subvolume for their data files, rather than a directory - and now they get their own btree. In this example it may be none of those things, and just this poor SSD was having to erase blocks on demand, and that alone was killing performance. > 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. space_cache=v2 should be the default soon. And discard=async has a good chance of being made the default but I don't know the time frame. It landed in kernel 5.6, even though Facebook has been testing it everywhere for the past six months. You can get these kinds of perturbed or pathological SSD behaviors on other file systems. But they're less likely to get there because by overwriting they're actively giving hints what blocks are ready for cell erasure by the SSD firmware. You will not see the reported behavior on a HDD. There's no FTL, and no cell erasure delay. It is a combination of events conspiring together, there isn't any one direct cause. Change any one of them and the problem goes away. -- Chris Murphy _______________________________________________ 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
