Updating atime affects system performance. What is happening and what to do about it — read in the article.
Every time I upgrade Linux on my home computer, I have to tackle certain tasks. Over the years, this has become a habit: I back up my files, wipe the system, install everything from scratch, restore my files, and then reinstall my favorite applications. I also adjust system settings to my liking. Sometimes, this takes too much time. Recently, I thought about whether I really need this headache.
atime — one of three timestamps for files in Linux (more on this later). In particular, I was wondering whether it’s still worth disabling atime in later Linux systems. Since atime is updated each time a file is accessed, I realized it has a significant impact on system performance.
Recently, I upgraded to Fedora 32 and, out of habit, started by disabling atime. I wondered: do I need it at all? I decided to investigate this issue and here’s what I found.
A bit about file timestamps
To understand this, you need to take a step back and remember a few things about Linux file systems and how the kernel assigns timestamps to files and directories. You can see the last modification date of files and directories by running the command ls -l (long) or simply checking this information in the file manager. But behind the scenes, the Linux kernel keeps track of several timestamps for files and directories:
- When the file was last modified (mtime)
- When the properties and metadata of the file were last changed (ctime)
- When the file was last accessed (atime)
- You can use the command stat, to view data about the file or directory. Here is a file /etc/fstab from one of my test servers:
$ stat fstab
File: fstab
Size: 261 Blocks: 8 IO Block: 4096 regular file
Device: b303h/45827d Inode: 2097285 Links: 1
Access: (0664/-rw-rw-r--) Uid: ( 0/ root) Gid: ( 0/ root)
Context: system_u:object_r:etc_t:s0
Access: 2019-04-25 21:10:18.083325111 -0500
Modify: 2019-05-16 10:46:47.427686706 -0500
Change: 2019-05-16 10:46:47.434686674 -0500
Birth: 2019-04-25 21:03:11.840496275 -0500Here you can see that this file was created on April 25, 2019, when I installed the system. My file /etc/fstab was last modified on May 16, 2019, and all other attributes were changed around the same time.
If I copy /etc/fstab in the new file, dates change, indicating that this is a new file:
$ sudo cp fstab fstab.bak
$ stat fstab.bak
File: fstab.bak
Size: 261 Blocks: 8 IO Block: 4096 regular file
Device: b303h/45827d Inode: 2105664 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Context: unconfined_u:object_r:etc_t:s0
Access: 2020-05-12 17:53:58.442659986 -0500
Modify: 2020-05-12 17:53:58.443659981 -0500
Change: 2020-05-12 17:53:58.443659981 -0500
Birth: 2020-05-12 17:53:58.442659986 -0500But if I simply rename the file without changing its contents, Linux will only update the file's modification time:
$ sudo mv fstab.bak fstab.tmp
$ stat fstab.tmp
File: fstab.tmp
Size: 261 Blocks: 8 IO Block: 4096 regular file
Device: b303h/45827d Inode: 2105664 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Context: unconfined_u:object_r:etc_t:s0
Access: 2020-05-12 17:53:58.442659986 -0500
Modify: 2020-05-12 17:53:58.443659981 -0500
Change: 2020-05-12 17:54:24.576508232 -0500
Birth: 2020-05-12 17:53:58.442659986 -0500These timestamps are very useful for certain Unix programs. For example, biff is a program that notifies you of new email messages. Nowadays, very few people use , but in the days when mailboxes were local to the system, biff was quite widely used.
How does the program know if you have new mail in your inbox? biff compares the last modification time (when the incoming mail file was updated with a new email message) and the last access time (the last time you checked your email). If the modification occurred later than the last access, then biff will understand that a new letter has arrived and will notify you about it. The Mutt mail client works in a similar way.
The last access timestamp is also useful if you need to gather filesystem usage statistics and tune performance. System administrators need to know which objects are being accessed in order to properly configure the filesystem.
But most modern programs no longer need this timestamp, which has led to suggestions to discontinue its use. In 2007, Linus Torvalds and several other kernel developers discussed atime in the context of performance issues. Linux kernel developer Ingo Molnar made the following comment about atime and the ext3 filesystem:
It’s quite strange that every Linux desktop and server suffers from a noticeable input-output performance drop due to constant atime updates, even though there are only two real users: tmpwatch [which can be configured to use ctime, so this isn't a major issue] and some backup tools.
However, people still use certain programs that rely on this timestamp. Therefore, removing atime would disrupt their functionality. Linux kernel developers shouldn't compromise user freedom.
Solomon's solution
Linux distributions come with numerous applications, and additionally, users can download and install other programs as per their needs. This is a key advantage of open-source OS. However, it complicates the optimization of your file system's performance. Removing resource-heavy components can disrupt system functionality.
As a compromise, the Linux kernel developers implemented a new option called relaytime, which aims to balance performance and compatibility:
atime is updated only if the previous access time is less than the current modification time or status change... Starting with Linux 2.6.30, the kernel uses this option by default (unless noatime is specified)... Additionally, starting from Linux 2.6.30, the last access time of a file is always updated if it is over 1 day old.
Modern Linux systems (starting with Linux 2.6.30 released in 2009) already utilize relaytime, which should provide a significant performance boost. This means you don't need to adjust the file, /etc/fstab, and with relaytime, you can rely on the default value.
Improving system performance with noatime
But if you want to configure your system for maximum performance, disabling atime is still an option.
Performance changes may not be very noticeable on very fast modern disks (such as NVME or Fast SSD), but there is a slight improvement.
If you know you aren't using software that requires atime, you can slightly boost performance by enabling the noatime option in the file. /etc /fstabAfter this, the kernel will not continuously update atime. Use the noatime option when mounting the file system:
/dev/mapper/fedora_localhost--live-root / ext4 defaults,noatime,x-systemd.device-timeout=0 1 1
UUID=be37c451-915e-4355-95c4-654729cf662a /boot ext4 defaults,noatime 1 2
UUID=C594-12B1 /boot/efi vfat umask=0077,shortname=winnt 0 2
/dev/mapper/fedora_localhost--live-home /home ext4 defaults,noatime,x-systemd.device-timeout=0 1 2
/dev/mapper/fedora_localhost--live-swap none swap defaults,x-systemd.device-timeout=0 0 0Changes will take effect on the next reboot.
Advertising
Need a server to host your website? Our company offers with daily or one-time payment, each server is connected to a 500 Megabit internet channel and is protected against DDoS attacks for free!
Source: habr.com
