{"id":4791,"date":"2024-04-11T03:00:00","date_gmt":"2024-04-11T07:00:00","guid":{"rendered":"https:\/\/www.both.org\/?p=4791"},"modified":"2024-04-05T13:39:28","modified_gmt":"2024-04-05T17:39:28","slug":"tweak-your-system-performance-with-noatime","status":"publish","type":"post","link":"https:\/\/www.both.org\/?p=4791","title":{"rendered":"Tweak your system performance with \u2018noatime\u2019"},"content":{"rendered":"
\r\n
\r\n \r\n <\/i>\r\n <\/a>\r\n <\/span>\r\n<\/div><\/div>\n

Whenever I install a new Linux system, whether that\u2019s Linux on my desktop computer or a server distribution on my Raspberry Pi, I have a list of tasks that I do every time. These are habits I developed from my time, long ago, as a Unix systems administrator: backup the files, wipe the system, reinstall from scratch, restore the files, and install any extra applications.<\/p>\n\n\n\n

I also make a few tweaks to the system to improve performance. One such tweak is atime<\/code>, one of the three key timestamps that Linux tracks on every file.<\/p>\n\n\n\n

Understanding file timestamps<\/h2>\n\n\n\n

You probably already know about the \u201cLast Modified\u201d timestamp on files and directories. You can see this output when you run the ls -l<\/code> (long) command to view files ina directory; you\u2019ll also see the \u201cLast Modified\u201d timestamp in any file manager. But behind the scenes, Linux actually tracks several timestamps on files and directories:<\/p>\n\n\n\n

    \n
  • mtime<\/strong>: When the file was last modified<\/li>\n\n\n\n
  • ctime<\/strong>: When the file was last changed<\/li>\n\n\n\n
  • atime<\/strong>: When the file was last accessed<\/li>\n<\/ul>\n\n\n\n

    You can use the stat<\/code> command to view these details for any file. Here\u2019s one example for the Apache web server configuration file on my personal web server in my home office:<\/p>\n\n\n\n

    $ stat \/etc\/httpd\/conf\/httpd.conf \n  File: \/etc\/httpd\/conf\/httpd.conf\n  Size: 12303       Blocks: 32         IO Block: 4096   regular file\nDevice: 253,0   Inode: 37749479    Links: 1\nAccess: (0644\/-rw-r--r--)  Uid: (    0\/    root)   Gid: (    0\/    root)\nContext: system_u:object_r:httpd_config_t:s0\nAccess: 2024-03-31 00:00:01.198883654 -0500\nModify: 2023-12-31 18:12:27.216328620 -0600\nChange: 2023-12-31 18:12:27.225328576 -0600\n Birth: 2023-12-31 18:12:27.215328625 -0600<\/code><\/pre>\n\n\n\n
    This file was created on December 31, 2023. That\u2019s when I installed Linux on this Raspberry Pi. I haven\u2019t needed to modify the httpd.conf<\/code> file since then, so the file has remained unchanged since then. But I recently viewed it, to look for a particular setting on the web server; by looking in the file using cat<\/code>, Linux updated the \u201cAccess Time\u201d or atime<\/code> timestamp.<\/p>\n\n\n\n
    If I copy the httpd.conf<\/code> file to a backup file, all of the timestamps change, indicating that this is a new file:<\/p>\n\n\n\n
    $ cp \/etc\/httpd\/conf\/httpd.conf \/tmp\/httpd.bak\n$ stat \/tmp\/httpd.bak \n  File: \/tmp\/httpd.bak\n  Size: 12303       Blocks: 32         IO Block: 4096   regular file\nDevice: 0,37    Inode: 253         Links: 1\nAccess: (0644\/-rw-r--r--)  Uid: ( 1000\/   jhall)   Gid: ( 1000\/   jhall)\nContext: unconfined_u:object_r:user_tmp_t:s0\nAccess: 2024-04-05 12:13:04.247401082 -0500\nModify: 2024-04-05 12:13:04.249401072 -0500\nChange: 2024-04-05 12:13:04.249401072 -0500\n Birth: 2024-04-05 12:13:04.247401082 -0500<\/code><\/pre>\n\n\n\n
    But if I rename the file, Linux doesn\u2019t update atime<\/code> or mtime<\/code> because I didn\u2019t access the file\u2019s contents (atime<\/code>) or otherwise modify the text (mtime<\/code>):<\/p>\n\n\n\n
    $ mv \/tmp\/httpd.bak \/tmp\/httpd.tmp\n$ stat \/tmp\/httpd.tmp\n  File: \/tmp\/httpd.tmp\n  Size: 12303       Blocks: 32         IO Block: 4096   regular file\nDevice: 0,37    Inode: 253         Links: 1\nAccess: (0644\/-rw-r--r--)  Uid: ( 1000\/   jhall)   Gid: ( 1000\/   jhall)\nContext: unconfined_u:object_r:user_tmp_t:s0\nAccess: 2024-04-05 12:13:04.247401082 -0500\nModify: 2024-04-05 12:13:04.249401072 -0500\nChange: 2024-04-05 12:14:24.902015034 -0500\n Birth: 2024-04-05 12:13:04.247401082 -0500<\/code><\/pre>\n\n\n\n
    Notice that the \u201cLast Changed\u201d time (ctime<\/code>) has been updated, because I changed the file\u2019s name.<\/p>\n\n\n\n
    Why \u2018atime\u2019?<\/h2>\n\n\n\n
    The \u201cLast Accessed\u201d (atime<\/code>) is useful for certain legacy programs. For example, biff<\/strong> is an old mail notification program that alerts you when you have a new email message waiting for your attention. You don\u2019t see many people using biff<\/strong> in modern times, but in the days when mailboxes were local to the workstation you were using, biff<\/strong> was quite common.<\/p>\n\n\n\n
    biff<\/strong> compared the \u201cLast Modified\u201d time (when the Inbox was last updated with a new email message) and the \u201cLast Accessed\u201d time (the last time you read your email). If mtime<\/code> was more recent than atime<\/code>, then biff<\/strong> knew that an email had arrived since you last looked at your Inbox, and let you know. The Mutt<\/strong> email client does something similar to alert you to new email messages.<\/p>\n\n\n\n
    The \u201cLast Accessed\u201d time is also useful if you need to do filesystem maintenance or performance tweaking. On large Linux systems, administrators may need to know what\u2019s being accessed more frequently so they can tune performance appropriately. This might involve moving less-frequently used files to slower, high-density storage and more-frequently used files to faster disks.<\/p>\n\n\n\n
    But desktop systems and other \u201cpersonal use\u201d computers don\u2019t need the \u201cLast Accessed\u201d time, so there\u2019s been some argument to not use it at all. For example, Linux kernel developer Ingo Molnar commented about\u00a0atime<\/code>\u00a0and filesystem performance:<\/p>\n\n\n\n
    \n
    It\u2019s kind of weird that every Linux desktop and server is hurt by a noticeable IO performance slowdown due to the constant atime updates, while there\u2019s just two real users of it: tmpwatch [which can be configured to use ctime so it\u2019s not a big issue] and some backup tools. (Ok, and mail-notify too i guess.) Out of tens of thousands of applications.<\/p>\n<\/blockquote>\n\n\n\n
    But some people use a few programs that rely on\u00a0atime<\/code>\u00a0so Linux keeps updating the\u00a0atime<\/code>\u00a0feature.<\/p>\n\n\n\n
    Tweaking performance with \u2018noatime\u2019<\/h2>\n\n\n\n
    If you want to get a boost in desktop performance, you can disable atime<\/code> on your system. You can also use this method on servers, but be careful that you do not run software that relies on the \u201cLast Accessed\u201d time. In my experience, modern desktop environments don\u2019t use atime<\/code> so I disable it on the Linux systems I use.<\/p>\n\n\n\n
    To disable atime<\/code>, add the noatime<\/code> filesystem option when your system mounts the storage for your computer. I usually add mine after the defaults<\/code> entry in \/etc\/fstab<\/code>:<\/p>\n\n\n\n
    UUID=93402b76-22d5-4533-ad1e-b8b94ccb24c0 \/                       btrfs   subvol=root,compress=zstd:1,x-systemd.device-timeout=0,noatime 0 0\nUUID=aa7dd33b-bd3c-4b12-a2e1-6cb0bf28a2e6 \/boot                   ext4    defaults,noatime        1 2\nUUID=C594-12B1          \/boot\/efi               vfat    umask=0077,shortname=winnt 0 2\nUUID=93402b76-22d5-4533-ad1e-b8b94ccb24c0 \/home                   btrfs   subvol=home,compress=zstd:1,x-systemd.device-timeout=0,noatime 0 0<\/code><\/pre>\n\n\n\n
    This feature takes effect the next time you reboot. Whenever I reinstall my desktop system at home with a new version of Linux, the first thing I do after installing is add noatime<\/code>, then reboot before I apply any system updates. Running the first system update after installing a fresh Linux will update many packages and files. Using noatime<\/code> usually gives a slight but noticeable performance improvement on my computer<\/p>\n\n\n\n
    However, if you use very fast storage such as a high-performance SSD or NVME for your root and home filesystems, you may not notice as much of an improvement.<\/p>\n","protected":false},"excerpt":{"rendered":"
    Turn off \u201caccess time\u201d to make a slight but noticeable improvement on system performance.<\/p>\n","protected":false},"author":33,"featured_media":3306,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_lmt_disableupdate":"","_lmt_disable":"","footnotes":""},"categories":[100,5,328,89],"tags":[91,97],"class_list":["post-4791","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-command-line","category-linux","category-storage-management","category-system-administration","tag-linux","tag-sysadmin"],"modified_by":"Jim Hall","_links":{"self":[{"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/posts\/4791","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/users\/33"}],"replies":[{"embeddable":true,"href":"https:\/\/www.both.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=4791"}],"version-history":[{"count":1,"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/posts\/4791\/revisions"}],"predecessor-version":[{"id":4793,"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/posts\/4791\/revisions\/4793"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.both.org\/index.php?rest_route=\/wp\/v2\/media\/3306"}],"wp:attachment":[{"href":"https:\/\/www.both.org\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=4791"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.both.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=4791"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.both.org\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=4791"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}