On Sat, Sep 5, 2020 at 11:22 AM Dominique Martinet <asmadeus@xxxxxxxxxxxxx> wrote: > > 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. Or even just 'chattr +A' on certain directories to exclude from atime updates. It's something the desktop can just do as a courtesy. > (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) Yeah and at which point there is a snapshot/rollback regime in Fedora, it isn't going to be keeping 100's of snapshots around unless the user configures it. Silverblue defaults to two deployments. And traditional installs have three complete kernel installs, with a fourth partial one in the form of a rescue boot option (which is just a nohostonly initramfs). I figure somewhere around 3-5 root snapshots? And /home snapshots are up to the user, they can configure it however they want. I don't tend to have more than one per day, frequently only one per 2 week period. This is very lightweight, and almost always gets me the kind of "what if" retention behavior I want. I got ensnared quite badly recently with a restorecon behavior, where it insisted on relabeling everything in /mnt. And at the time I had the top-level of a ~1T Btrfs file system with 100's of snapshots in it, which to a program looks like 100 directories with 1TB each of unique data, so it tried to relabel 100TB. Fortunately almost all of those snapshots were read-only so the relabel caused no writes but it took me a while to figure out what was going on with a tiny dnf update that was taking an incredibly long time. (This is not an atime update but it's the same concept and effect in terms of exploding metadata updates.) -- 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
