Where is noatime safe to use?












1















I am trying to optimize my new fs layout, and I wondered, where is it safe to use noatime? I understand that e.g. mutt uses the access/creation/modify time, and whatever else may be using that, in whichever dir.



Following a ton of guides, I have partitioned my dirs according to different use-cases, but I don't really know, where is it safe to put noatime?



dirs / flags:



/               defaults
(/bin
/sbin
/lib*
/etc
/root
/dev ...)

/boot defaults
/boot/EFI defaults

/usr defaults,ro,nodev
NOTE: dpkg needs rw
/usr/share defaults,ro,nodev,nosuid

/var defaults,nodev
NOTE: /var/lib/dpkg/info -> exec
/var/tmp defaults,nodev,nosuid,noexec
/var/log defaults,nodev,nosuid,noexec

/opt defaults,nodev

/tmp defaults,nodev,nosuid,noexec
NOTE: some installer may need exec

/home defaults,nodev,nosuid









share|improve this question



























    1















    I am trying to optimize my new fs layout, and I wondered, where is it safe to use noatime? I understand that e.g. mutt uses the access/creation/modify time, and whatever else may be using that, in whichever dir.



    Following a ton of guides, I have partitioned my dirs according to different use-cases, but I don't really know, where is it safe to put noatime?



    dirs / flags:



    /               defaults
    (/bin
    /sbin
    /lib*
    /etc
    /root
    /dev ...)

    /boot defaults
    /boot/EFI defaults

    /usr defaults,ro,nodev
    NOTE: dpkg needs rw
    /usr/share defaults,ro,nodev,nosuid

    /var defaults,nodev
    NOTE: /var/lib/dpkg/info -> exec
    /var/tmp defaults,nodev,nosuid,noexec
    /var/log defaults,nodev,nosuid,noexec

    /opt defaults,nodev

    /tmp defaults,nodev,nosuid,noexec
    NOTE: some installer may need exec

    /home defaults,nodev,nosuid









    share|improve this question

























      1












      1








      1








      I am trying to optimize my new fs layout, and I wondered, where is it safe to use noatime? I understand that e.g. mutt uses the access/creation/modify time, and whatever else may be using that, in whichever dir.



      Following a ton of guides, I have partitioned my dirs according to different use-cases, but I don't really know, where is it safe to put noatime?



      dirs / flags:



      /               defaults
      (/bin
      /sbin
      /lib*
      /etc
      /root
      /dev ...)

      /boot defaults
      /boot/EFI defaults

      /usr defaults,ro,nodev
      NOTE: dpkg needs rw
      /usr/share defaults,ro,nodev,nosuid

      /var defaults,nodev
      NOTE: /var/lib/dpkg/info -> exec
      /var/tmp defaults,nodev,nosuid,noexec
      /var/log defaults,nodev,nosuid,noexec

      /opt defaults,nodev

      /tmp defaults,nodev,nosuid,noexec
      NOTE: some installer may need exec

      /home defaults,nodev,nosuid









      share|improve this question














      I am trying to optimize my new fs layout, and I wondered, where is it safe to use noatime? I understand that e.g. mutt uses the access/creation/modify time, and whatever else may be using that, in whichever dir.



      Following a ton of guides, I have partitioned my dirs according to different use-cases, but I don't really know, where is it safe to put noatime?



      dirs / flags:



      /               defaults
      (/bin
      /sbin
      /lib*
      /etc
      /root
      /dev ...)

      /boot defaults
      /boot/EFI defaults

      /usr defaults,ro,nodev
      NOTE: dpkg needs rw
      /usr/share defaults,ro,nodev,nosuid

      /var defaults,nodev
      NOTE: /var/lib/dpkg/info -> exec
      /var/tmp defaults,nodev,nosuid,noexec
      /var/log defaults,nodev,nosuid,noexec

      /opt defaults,nodev

      /tmp defaults,nodev,nosuid,noexec
      NOTE: some installer may need exec

      /home defaults,nodev,nosuid






      filesystem directory-structure atime






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Feb 6 at 11:04









      Zoltan K.Zoltan K.

      1083




      1083






















          1 Answer
          1






          active

          oldest

          votes


















          2














          AFAIK it's the very rare program indeed that relies on atime, and using noatime is safe virtually everywhere.



          The serverfault question Turning off atime on a filesystem says it's basically only mutt (when using an mbox mailbox) and there's an easy workaround anyway, or the very occasional program like tmpwatch or temporary file cleaners:




          mutt, an email client, uses file access times to monitor for new mail arriving on an mbox-formatted mailbox. Apparently, this problem is not serious, and is easy to work around.



          Other than that, it is difficult to find examples of things that break on noatime. I run a number of Linux servers with noatime on all filesystems, and I can't recall ever having seen any problems attributable to noatime.




          And using noatime could improve performance, perhaps by a lot over the old strictatime (but should still help a little over even today's standard relatime, saving every write on a flash/SSD is good):




          Linux: Replacing atime With relatime



          Submitted by Jeremy on August 7, 2007 - 11:26am



          In a recent lkml thread, Linus Torvalds was involved in a discussion about mounting filesystems with the noatime option for better performance, "'noatime,data=writeback' will quite likely be quite noticeable (with different effects for different loads), but almost nobody actually runs that way." He noted that he set O_NOATIME when writing git, "and it was an absolutely huge time-saver for the case of not having 'noatime' in the mount options. Certainly more than your estimated 10% under some loads." The discussion then looked at using the relatime mount option to improve the situation, "relative atime only updates the atime if the previous atime is older than the mtime or ctime. Like noatime, but useful for applications like mutt that need to know when a file has been read since it was last modified." Ingo Molnar stressed the significance of fixing this performance issue, "I cannot over-emphasize how much of a deal it is in practice. Atime updates are by far the biggest IO performance deficiency that Linux has today. Getting rid of atime updates would give us more everyday Linux performance than all the pagecache speedups of the past 10 years, combined." He submitted some patches to improve relatime, and noted about atime:




          "It's also perhaps the most stupid Unix design idea of all times. Unix is really nice and well done, but think about this a bit: 'For every file that is read from the disk, lets do a ... write to the disk! And, for every file that is already cached and which we read from the cache ... do a write to the disk!'"





          There is an answer on serverfault (Drawbacks of mounting a filesystem with noatime?) saying that for the last 10 years or so, mounting with noatime apparently has no problems:




          There exist applications that will move files off to a secondary storage if they haven't been accessed for a certain time period. Obviously, they need the atime.



          Other than that, I don't see much use for this (anymore), especially as file managers these days have a tendency to open files to generate previews, therefore modifiying the atime just while browsing a directory.



          I always mount with noatime these days.



          answered Jul 29 '09 at 11:09

          Sven♦

          86.4k







          share|improve this answer


























          • For anyone who might read it later, I would like to stress an option I have found while reading through the references in the accepted answer and in line with the feats noatime achieves: The data=writeback mount/fs option is also interesting, although more dangerous in case of a system crash. As someone commented, it can make ext4 ro (bug). A work-around can be: make it the default fs setting, as opposed to a mount or /etc/fstab option: tune2fs -o journal_data_writeback /dev/sdXY

            – Zoltan K.
            Mar 6 at 13:53














          Your Answer








          StackExchange.ready(function() {
          var channelOptions = {
          tags: "".split(" "),
          id: "89"
          };
          initTagRenderer("".split(" "), "".split(" "), channelOptions);

          StackExchange.using("externalEditor", function() {
          // Have to fire editor after snippets, if snippets enabled
          if (StackExchange.settings.snippets.snippetsEnabled) {
          StackExchange.using("snippets", function() {
          createEditor();
          });
          }
          else {
          createEditor();
          }
          });

          function createEditor() {
          StackExchange.prepareEditor({
          heartbeatType: 'answer',
          autoActivateHeartbeat: false,
          convertImagesToLinks: true,
          noModals: true,
          showLowRepImageUploadWarning: true,
          reputationToPostImages: 10,
          bindNavPrevention: true,
          postfix: "",
          imageUploader: {
          brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
          contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
          allowUrls: true
          },
          onDemand: true,
          discardSelector: ".discard-answer"
          ,immediatelyShowMarkdownHelp:true
          });


          }
          });














          draft saved

          draft discarded


















          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1116073%2fwhere-is-noatime-safe-to-use%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown

























          1 Answer
          1






          active

          oldest

          votes








          1 Answer
          1






          active

          oldest

          votes









          active

          oldest

          votes






          active

          oldest

          votes









          2














          AFAIK it's the very rare program indeed that relies on atime, and using noatime is safe virtually everywhere.



          The serverfault question Turning off atime on a filesystem says it's basically only mutt (when using an mbox mailbox) and there's an easy workaround anyway, or the very occasional program like tmpwatch or temporary file cleaners:




          mutt, an email client, uses file access times to monitor for new mail arriving on an mbox-formatted mailbox. Apparently, this problem is not serious, and is easy to work around.



          Other than that, it is difficult to find examples of things that break on noatime. I run a number of Linux servers with noatime on all filesystems, and I can't recall ever having seen any problems attributable to noatime.




          And using noatime could improve performance, perhaps by a lot over the old strictatime (but should still help a little over even today's standard relatime, saving every write on a flash/SSD is good):




          Linux: Replacing atime With relatime



          Submitted by Jeremy on August 7, 2007 - 11:26am



          In a recent lkml thread, Linus Torvalds was involved in a discussion about mounting filesystems with the noatime option for better performance, "'noatime,data=writeback' will quite likely be quite noticeable (with different effects for different loads), but almost nobody actually runs that way." He noted that he set O_NOATIME when writing git, "and it was an absolutely huge time-saver for the case of not having 'noatime' in the mount options. Certainly more than your estimated 10% under some loads." The discussion then looked at using the relatime mount option to improve the situation, "relative atime only updates the atime if the previous atime is older than the mtime or ctime. Like noatime, but useful for applications like mutt that need to know when a file has been read since it was last modified." Ingo Molnar stressed the significance of fixing this performance issue, "I cannot over-emphasize how much of a deal it is in practice. Atime updates are by far the biggest IO performance deficiency that Linux has today. Getting rid of atime updates would give us more everyday Linux performance than all the pagecache speedups of the past 10 years, combined." He submitted some patches to improve relatime, and noted about atime:




          "It's also perhaps the most stupid Unix design idea of all times. Unix is really nice and well done, but think about this a bit: 'For every file that is read from the disk, lets do a ... write to the disk! And, for every file that is already cached and which we read from the cache ... do a write to the disk!'"





          There is an answer on serverfault (Drawbacks of mounting a filesystem with noatime?) saying that for the last 10 years or so, mounting with noatime apparently has no problems:




          There exist applications that will move files off to a secondary storage if they haven't been accessed for a certain time period. Obviously, they need the atime.



          Other than that, I don't see much use for this (anymore), especially as file managers these days have a tendency to open files to generate previews, therefore modifiying the atime just while browsing a directory.



          I always mount with noatime these days.



          answered Jul 29 '09 at 11:09

          Sven♦

          86.4k







          share|improve this answer


























          • For anyone who might read it later, I would like to stress an option I have found while reading through the references in the accepted answer and in line with the feats noatime achieves: The data=writeback mount/fs option is also interesting, although more dangerous in case of a system crash. As someone commented, it can make ext4 ro (bug). A work-around can be: make it the default fs setting, as opposed to a mount or /etc/fstab option: tune2fs -o journal_data_writeback /dev/sdXY

            – Zoltan K.
            Mar 6 at 13:53


















          2














          AFAIK it's the very rare program indeed that relies on atime, and using noatime is safe virtually everywhere.



          The serverfault question Turning off atime on a filesystem says it's basically only mutt (when using an mbox mailbox) and there's an easy workaround anyway, or the very occasional program like tmpwatch or temporary file cleaners:




          mutt, an email client, uses file access times to monitor for new mail arriving on an mbox-formatted mailbox. Apparently, this problem is not serious, and is easy to work around.



          Other than that, it is difficult to find examples of things that break on noatime. I run a number of Linux servers with noatime on all filesystems, and I can't recall ever having seen any problems attributable to noatime.




          And using noatime could improve performance, perhaps by a lot over the old strictatime (but should still help a little over even today's standard relatime, saving every write on a flash/SSD is good):




          Linux: Replacing atime With relatime



          Submitted by Jeremy on August 7, 2007 - 11:26am



          In a recent lkml thread, Linus Torvalds was involved in a discussion about mounting filesystems with the noatime option for better performance, "'noatime,data=writeback' will quite likely be quite noticeable (with different effects for different loads), but almost nobody actually runs that way." He noted that he set O_NOATIME when writing git, "and it was an absolutely huge time-saver for the case of not having 'noatime' in the mount options. Certainly more than your estimated 10% under some loads." The discussion then looked at using the relatime mount option to improve the situation, "relative atime only updates the atime if the previous atime is older than the mtime or ctime. Like noatime, but useful for applications like mutt that need to know when a file has been read since it was last modified." Ingo Molnar stressed the significance of fixing this performance issue, "I cannot over-emphasize how much of a deal it is in practice. Atime updates are by far the biggest IO performance deficiency that Linux has today. Getting rid of atime updates would give us more everyday Linux performance than all the pagecache speedups of the past 10 years, combined." He submitted some patches to improve relatime, and noted about atime:




          "It's also perhaps the most stupid Unix design idea of all times. Unix is really nice and well done, but think about this a bit: 'For every file that is read from the disk, lets do a ... write to the disk! And, for every file that is already cached and which we read from the cache ... do a write to the disk!'"





          There is an answer on serverfault (Drawbacks of mounting a filesystem with noatime?) saying that for the last 10 years or so, mounting with noatime apparently has no problems:




          There exist applications that will move files off to a secondary storage if they haven't been accessed for a certain time period. Obviously, they need the atime.



          Other than that, I don't see much use for this (anymore), especially as file managers these days have a tendency to open files to generate previews, therefore modifiying the atime just while browsing a directory.



          I always mount with noatime these days.



          answered Jul 29 '09 at 11:09

          Sven♦

          86.4k







          share|improve this answer


























          • For anyone who might read it later, I would like to stress an option I have found while reading through the references in the accepted answer and in line with the feats noatime achieves: The data=writeback mount/fs option is also interesting, although more dangerous in case of a system crash. As someone commented, it can make ext4 ro (bug). A work-around can be: make it the default fs setting, as opposed to a mount or /etc/fstab option: tune2fs -o journal_data_writeback /dev/sdXY

            – Zoltan K.
            Mar 6 at 13:53
















          2












          2








          2







          AFAIK it's the very rare program indeed that relies on atime, and using noatime is safe virtually everywhere.



          The serverfault question Turning off atime on a filesystem says it's basically only mutt (when using an mbox mailbox) and there's an easy workaround anyway, or the very occasional program like tmpwatch or temporary file cleaners:




          mutt, an email client, uses file access times to monitor for new mail arriving on an mbox-formatted mailbox. Apparently, this problem is not serious, and is easy to work around.



          Other than that, it is difficult to find examples of things that break on noatime. I run a number of Linux servers with noatime on all filesystems, and I can't recall ever having seen any problems attributable to noatime.




          And using noatime could improve performance, perhaps by a lot over the old strictatime (but should still help a little over even today's standard relatime, saving every write on a flash/SSD is good):




          Linux: Replacing atime With relatime



          Submitted by Jeremy on August 7, 2007 - 11:26am



          In a recent lkml thread, Linus Torvalds was involved in a discussion about mounting filesystems with the noatime option for better performance, "'noatime,data=writeback' will quite likely be quite noticeable (with different effects for different loads), but almost nobody actually runs that way." He noted that he set O_NOATIME when writing git, "and it was an absolutely huge time-saver for the case of not having 'noatime' in the mount options. Certainly more than your estimated 10% under some loads." The discussion then looked at using the relatime mount option to improve the situation, "relative atime only updates the atime if the previous atime is older than the mtime or ctime. Like noatime, but useful for applications like mutt that need to know when a file has been read since it was last modified." Ingo Molnar stressed the significance of fixing this performance issue, "I cannot over-emphasize how much of a deal it is in practice. Atime updates are by far the biggest IO performance deficiency that Linux has today. Getting rid of atime updates would give us more everyday Linux performance than all the pagecache speedups of the past 10 years, combined." He submitted some patches to improve relatime, and noted about atime:




          "It's also perhaps the most stupid Unix design idea of all times. Unix is really nice and well done, but think about this a bit: 'For every file that is read from the disk, lets do a ... write to the disk! And, for every file that is already cached and which we read from the cache ... do a write to the disk!'"





          There is an answer on serverfault (Drawbacks of mounting a filesystem with noatime?) saying that for the last 10 years or so, mounting with noatime apparently has no problems:




          There exist applications that will move files off to a secondary storage if they haven't been accessed for a certain time period. Obviously, they need the atime.



          Other than that, I don't see much use for this (anymore), especially as file managers these days have a tendency to open files to generate previews, therefore modifiying the atime just while browsing a directory.



          I always mount with noatime these days.



          answered Jul 29 '09 at 11:09

          Sven♦

          86.4k







          share|improve this answer















          AFAIK it's the very rare program indeed that relies on atime, and using noatime is safe virtually everywhere.



          The serverfault question Turning off atime on a filesystem says it's basically only mutt (when using an mbox mailbox) and there's an easy workaround anyway, or the very occasional program like tmpwatch or temporary file cleaners:




          mutt, an email client, uses file access times to monitor for new mail arriving on an mbox-formatted mailbox. Apparently, this problem is not serious, and is easy to work around.



          Other than that, it is difficult to find examples of things that break on noatime. I run a number of Linux servers with noatime on all filesystems, and I can't recall ever having seen any problems attributable to noatime.




          And using noatime could improve performance, perhaps by a lot over the old strictatime (but should still help a little over even today's standard relatime, saving every write on a flash/SSD is good):




          Linux: Replacing atime With relatime



          Submitted by Jeremy on August 7, 2007 - 11:26am



          In a recent lkml thread, Linus Torvalds was involved in a discussion about mounting filesystems with the noatime option for better performance, "'noatime,data=writeback' will quite likely be quite noticeable (with different effects for different loads), but almost nobody actually runs that way." He noted that he set O_NOATIME when writing git, "and it was an absolutely huge time-saver for the case of not having 'noatime' in the mount options. Certainly more than your estimated 10% under some loads." The discussion then looked at using the relatime mount option to improve the situation, "relative atime only updates the atime if the previous atime is older than the mtime or ctime. Like noatime, but useful for applications like mutt that need to know when a file has been read since it was last modified." Ingo Molnar stressed the significance of fixing this performance issue, "I cannot over-emphasize how much of a deal it is in practice. Atime updates are by far the biggest IO performance deficiency that Linux has today. Getting rid of atime updates would give us more everyday Linux performance than all the pagecache speedups of the past 10 years, combined." He submitted some patches to improve relatime, and noted about atime:




          "It's also perhaps the most stupid Unix design idea of all times. Unix is really nice and well done, but think about this a bit: 'For every file that is read from the disk, lets do a ... write to the disk! And, for every file that is already cached and which we read from the cache ... do a write to the disk!'"





          There is an answer on serverfault (Drawbacks of mounting a filesystem with noatime?) saying that for the last 10 years or so, mounting with noatime apparently has no problems:




          There exist applications that will move files off to a secondary storage if they haven't been accessed for a certain time period. Obviously, they need the atime.



          Other than that, I don't see much use for this (anymore), especially as file managers these days have a tendency to open files to generate previews, therefore modifiying the atime just while browsing a directory.



          I always mount with noatime these days.



          answered Jul 29 '09 at 11:09

          Sven♦

          86.4k








          share|improve this answer














          share|improve this answer



          share|improve this answer








          edited Feb 6 at 12:29

























          answered Feb 6 at 12:20









          Xen2050Xen2050

          6,92622344




          6,92622344













          • For anyone who might read it later, I would like to stress an option I have found while reading through the references in the accepted answer and in line with the feats noatime achieves: The data=writeback mount/fs option is also interesting, although more dangerous in case of a system crash. As someone commented, it can make ext4 ro (bug). A work-around can be: make it the default fs setting, as opposed to a mount or /etc/fstab option: tune2fs -o journal_data_writeback /dev/sdXY

            – Zoltan K.
            Mar 6 at 13:53





















          • For anyone who might read it later, I would like to stress an option I have found while reading through the references in the accepted answer and in line with the feats noatime achieves: The data=writeback mount/fs option is also interesting, although more dangerous in case of a system crash. As someone commented, it can make ext4 ro (bug). A work-around can be: make it the default fs setting, as opposed to a mount or /etc/fstab option: tune2fs -o journal_data_writeback /dev/sdXY

            – Zoltan K.
            Mar 6 at 13:53



















          For anyone who might read it later, I would like to stress an option I have found while reading through the references in the accepted answer and in line with the feats noatime achieves: The data=writeback mount/fs option is also interesting, although more dangerous in case of a system crash. As someone commented, it can make ext4 ro (bug). A work-around can be: make it the default fs setting, as opposed to a mount or /etc/fstab option: tune2fs -o journal_data_writeback /dev/sdXY

          – Zoltan K.
          Mar 6 at 13:53







          For anyone who might read it later, I would like to stress an option I have found while reading through the references in the accepted answer and in line with the feats noatime achieves: The data=writeback mount/fs option is also interesting, although more dangerous in case of a system crash. As someone commented, it can make ext4 ro (bug). A work-around can be: make it the default fs setting, as opposed to a mount or /etc/fstab option: tune2fs -o journal_data_writeback /dev/sdXY

          – Zoltan K.
          Mar 6 at 13:53




















          draft saved

          draft discarded




















































          Thanks for contributing an answer to Ask Ubuntu!


          • Please be sure to answer the question. Provide details and share your research!

          But avoid



          • Asking for help, clarification, or responding to other answers.

          • Making statements based on opinion; back them up with references or personal experience.


          To learn more, see our tips on writing great answers.




          draft saved


          draft discarded














          StackExchange.ready(
          function () {
          StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1116073%2fwhere-is-noatime-safe-to-use%23new-answer', 'question_page');
          }
          );

          Post as a guest















          Required, but never shown





















































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown

































          Required, but never shown














          Required, but never shown












          Required, but never shown







          Required, but never shown







          Popular posts from this blog

          Human spaceflight

          Can not write log (Is /dev/pts mounted?) - openpty in Ubuntu-on-Windows?

          File:DeusFollowingSea.jpg