On Sat, Sep 5, 2020 at 6:30 AM Neal Becker <ndbeck...@gmail.com> wrote:
> > If BTRFS is to become fedora default, we should consider this? > > "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 > > Ordinary desktop workloads I doubt show a performance difference. An overwriting file system will have a bunch of random writes to update its metadata in place. Btrfs will delay writes and it'll be one fairly sequential write commit - it has no fixed metadata locations the writes just go into free space. There might be more net writes in this case with Btrfs, but it really depends on how many files are being updated and in what time frame. With relatime, it's hard to say. But also, it won't happen again right away either, at least to those same files. The contrived case is to snapshot your root subvolume. Just one snapshot is enough. 'btrfs fi us /' to check the data and metadata usage. Use -r if you want raw values for more precision. And now 'grep -r beer /usr'. Give it a minute *after* the command returns, again due to delayed metadata writes. And check usage again. So what's going on is, the prior atimes are pinned in the snapshot of root. While root has its atimes all or mostly updated. That's maybe 100-200 megabytes of metadata writes. Even on a hard drive you won't likely notice that write, it'll take a couple seconds over ~1 minute of commit time. But if you've got a snapshot once per day, times ten days, and this kind of aggressive search function touching every file? Maybe an extra 1-2G of metadata being pinned For what it's worth, same thing happens with thin provisioning snapshots. And ZFS. It's a case worth understanding. And solving with some selective noatime mounts, which as a VFS mount, can be done per bind mount (and subvolume mounts are a pseudo-bind mount behind the scenes). I'd say it's not a problem per se. It's a possible optimization opportunity if the problem is big enough to be worth carving out noatime mounts by default. I use noatime full time for / and /home. I just checked three computers' /var/tmp and they are all less than 1MiB. My laptop, which I use the most by far, has 64KiB on /var/tmp. *shrug* Something is cleaning it up without needing atime updates. And I'm certainly not cleaning it up. GNOME Shell trash management uses .trashinfo files to time stamp everything to track their aging I presume. I use it. And have forgotten about Trash entirely until just now. 88MiB. And nothing in it has been there more than 7 days. I figured nothing was using it these days and it was a complete waste. If tracker uses atime, maybe I'll get more worried. But if it uses mtime, I'm not. -- Chris Murphy
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org
