Where is noatime safe to use?
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
add a comment |
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
add a comment |
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
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
filesystem directory-structure atime
asked Feb 6 at 11:04
Zoltan K.Zoltan K.
1083
1083
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
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
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: Thedata=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
add a comment |
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
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
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
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: Thedata=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
add a comment |
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
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: Thedata=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
add a comment |
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
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
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: Thedata=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
add a comment |
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: Thedata=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
add a comment |
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.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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