Florian Stecker posted on Sat, 12 Jan 2019 11:19:14 +0100 as excerpted: > $ mount | grep btrfs > /dev/sda8 on / type btrfs > (rw,relatime,ssd,space_cache,subvolid=5,subvol=/)
Unlikely to be apropos to the problem at hand, but FYI... Unless you have a known reason not to[1], running noatime with btrfs instead of the kernel-default relatime is strongly recommended, especially if you use btrfs snapshotting on the filesystem. The reasoning is that even tho relatime reduces the default access-time updates to once a day, it still likely-unnecessarily turns otherwise read- only operations into read-write operations, and atimes are metadata, which btrfs always COWs (copy-on-writes), meaning atime updates can trigger cascading metadata block-writes and much larger than anticipated[2] write-amplification, potentially hurting performance, yes, even for relatime, depending on your usage. In addition, if you're using snapshotting and not using noatime, it can easily happen that a large portion of the change between one snapshot and the next is simply atime updates, thus making the space referenced exclusively by individual affected snapshots far larger than it would otherwise be. --- [1] mutt is AFAIK the only widely used application that still depends on atime updates, and it only does so in certain modes, not with mbox-format mailboxes, for instance. So unless you're using it, or your backup solution happens to use atime, chances are quite high that noatime won't disrupt your usage at all. [2] Larger than anticipated write-amplification: Especially when you /thought/ you were only reading the files and hadn't considered the atime update that read could trigger, thus effectively generating infinity write amplification because the read access did an atime update and turned what otherwise wouldn't be a write operation at all into one! -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
