On Mon, Jun 29, 2020 at 11:56 AM Tom Seewald <tseewald@xxxxxxxxx> wrote: > > > 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. > > Do we know what use cases are expected to not be transparent if run on top of btrfs? Mainly it's databases, but not all of them. Postgresql seems particularly troublesome, and some folks are looking into that. > e.g. Will F33 users that run virtual machines and/or databases be expected to manually change settings in order to avoid performance degradation? No. I don't know yet where the 'chattr +C' will happen: libvirtd, virt-manager, the installer, or GNOME Boxes are all potential candidates. The user is not a potential candidate for having to set or know about these things. > Also do we know roughly how much of a performance hit those users will experience if they do not make any changes? Varies on the guest file system behavior. I regularly run btrfs guest on btrfs host, normally (datacow) and it's fine even for longer periods of time, I also use cache= unsafe. If I do this same thing with Windows (uses NTFS) as the guest, the fragmentation is impressive. The cow itself is not what costs. It's the accumulation of extents that have to be tracked. The nodatacow attribute on a backing file makes Btrfs behave like ext4/xfs for that one file. -- 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
