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







New contributor




Zoltan K. is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.

























    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







    New contributor




    Zoltan K. is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
    Check out our Code of Conduct.























      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







      New contributor




      Zoltan K. is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.












      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







      New contributor




      Zoltan K. is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.











      share|improve this question







      New contributor




      Zoltan K. is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.









      share|improve this question




      share|improve this question






      New contributor




      Zoltan K. is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.









      asked yesterday









      Zoltan K.Zoltan K.

      1083




      1083




      New contributor




      Zoltan K. is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.





      New contributor





      Zoltan K. is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.






      Zoltan K. is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
      Check out our Code of Conduct.






















          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

























            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
            });


            }
            });






            Zoltan K. is a new contributor. Be nice, and check out our Code of Conduct.










            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






























              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




























                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 yesterday

























                answered yesterday









                Xen2050Xen2050

                6,80112343




                6,80112343






















                    Zoltan K. is a new contributor. Be nice, and check out our Code of Conduct.










                    draft saved

                    draft discarded


















                    Zoltan K. is a new contributor. Be nice, and check out our Code of Conduct.













                    Zoltan K. is a new contributor. Be nice, and check out our Code of Conduct.












                    Zoltan K. is a new contributor. Be nice, and check out our Code of Conduct.
















                    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

                    Category:香港粉麵

                    List *all* the tuples!

                    Channel [V]