Matthew Miller wrote on Sat, Sep 05, 2020: > On Sat, Sep 05, 2020 at 08:46:37AM -0400, Neal Gompa wrote: > > > "BTRFS relatime vs. noatime - Huge Performance Difference - linux" https://www.reddit.com/r/linux/comments/imgler/btrfs_relatime_vs_noatime_huge_performance/?utm_source=amp&utm_medium=&utm_content=post_body > > It's something that's being looked at, see > > https://pagure.io/fedora-btrfs/project/issue/9 > > Huh. That's... unfortunate. > > I use atimes to keep ~/Downloads and ~/tmp from building up with cruft. I'm > sure there's plenty of other practical use cases. I guess with btrfs I > should make separate subvolumes for these or something? It really depends on what you plan on taking snapshots on -- for example if you don't plan on taking snapshots for your home, it won't cost all that much (basically where a classic filesystem would edit the atime in place, btrfs needs to copy it and remove the old one, but overall there really shouldn't be so much difference in how it feels) However if there are snapshots the metadata has to be copied over if the atime changes, it's really a fundamental of cow and snapshots... It will have to keep an extra copy of the metadata around everytime there's a new snapshot with different atimes. And at this point then yes it might make sense to have ~/tmp or whatever in a different subvolume, but I don't suppose regular users would want to have to think about this kind of things. (note I'm also a big user of atimes, for cruft but also for pointless reasons like just looking at what I was doing last year or sorting files by access times in my home all the time... So that just means being reasonable about snapshots for me :P) -- Dominique _______________________________________________ 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
