LWN: Comments on "Once upon atime"

noatime and mail programs

mathstuf — Sun, 03 Jun 2012 18:19:00 +0000

Experimenting a bit, the unread flag is marked by files being in the new/ directory in maildir. So maildir seems that the common implementation wouldn't care about atime at all.

noatime and mail programs

mirabilos — Sat, 02 Jun 2012 22:52:37 +0000

I believe it’s exactly the other way round, split-into-files formats would have issues with this.

Popularity contest

endecotp — Fri, 17 Aug 2007 15:19:00 +0000

The only program that I run that benefits from atime is Debian's "popcon", which records which packages are installed and which of those has been used recently. This would work well with the "update atime when > 1 day" approach suggested by Linus.

Once upon atime

xkahn — Sat, 11 Aug 2007 01:12:02 +0000

Interestingly, Microsoft seems to have looked at this issue in the past. From MSDN:

http://msdn2.microsoft.com/en-us/library/ms724290.aspx
Not all file systems can record creation and last access time and not
all file systems record them in the same manner. For example, on NT
FAT, create time has a resolution of 10 milliseconds, write time has a
resolution of 2 seconds, and access time has a resolution of 1 day
(really, the access date). On NTFS, access time has a resolution of 1
hour.

Does noatime imply nodiratime?

jzbiciak — Fri, 10 Aug 2007 14:26:25 +0000

Actually, Andrew Morton actually corrected Ingo on this point:

From: Andrew Morton 
To:	Ingo Molnar 
Subject: Re: [PATCH 00/23] per device dirty throttling -v8
Date:	Sun, 5 Aug 2007 00:29:34 -0700

On Sun, 5 Aug 2007 09:21:41 +0200 Ingo Molnar [email blocked] wrote:

> even on a noatime,nodiratime filesystem

noatime is a superset of nodiratime, btw.

I trust Andrew on this point. :-)

Once upon atime

liljencrantz — Fri, 10 Aug 2007 12:39:23 +0000

One other possibility is to keep atime updates in memory and only write them out to disk if the page was to be flushed to disk anyway. That would mean storing atimes in memory in a separate structure outside of the regular page.

The additional memory requirements should be relatively small, but the extra time needed to perform atime lookup might not be.

It would also mean that after a crash atimes will be wrong.

Does noatime imply nodiratime?

tarvin — Fri, 10 Aug 2007 06:41:24 +0000

OK. I've been using noatime systematically for years. And then I read about a prominent kernel developer like Molnar using both noatime and nodiratime, making me worried: Have I been missing out on I/O-performance for years?

- But your definite statement is comforting, thanks. I'll keep using just "noatime".

Does noatime imply nodiratime?

corbet — Thu, 09 Aug 2007 20:39:13 +0000

Yep, I'm sure. When in doubt, use the source. From touch_atime() in fs/inode.c:

void touch_atime(struct vfsmount *mnt, struct dentry *dentry)
{
        /* ... */
        if (inode->i_flags & S_NOATIME)
                return;
        if (IS_NOATIME(inode))
                return;
        if ((inode->i_sb->s_flags & MS_NODIRATIME) && S_ISDIR(inode->i_mode))
                return;

So if NOATIME is set, the NODIRATIME flag is never even checked.

Does noatime imply nodiratime?

tarvin — Thu, 09 Aug 2007 20:17:21 +0000

Are you sure about noatime implying nodiratime?

mount(8) states:
noatime Do not update inode access times on this file system[...] nodiratime Do not update directory inode access times on this filesystem.

while mount(2) puts it this way:
MS_NOATIME Do not update access times for (all types of) files on this file system. MS_NODIRATIME Do not update access times for directories on this file system.

I wonder how to interpret mount(2)'s (all types of) files for noatime: Is a directory considered a file in this context?

nodiratime

corbet — Thu, 09 Aug 2007 16:17:59 +0000

noatime implies nodiratime - it's a superset. You can use nodiratime by itself to turn off the updates on directories only. As you note, it does not seem to be widely used.

nodiratime

elanthis — Thu, 09 Aug 2007 16:12:40 +0000

Everyone knows about noatime, but it seems almost nobody uses nodiratime.

The thread this discussion was in notes that the kernel devs like Linus explicitly not only noatime, but also nodiratime. I ASSume that noatime only affects files and that directories need nodiratime.

Once upon atime

davecb — Thu, 09 Aug 2007 14:52:28 +0000

The article notes: It was suggested that, whenever a file's inode is to be written to disk anyway, the kernel might as well update atime as well. Alan Cox objected that this change might make the overall behavior less predictable, which might not be desirable.

Solaris has a "defer atime" mount option that does the atime update only when other disk I/O is scheduled, which gives a fairly fine-grained update, and makes the behavior less prefictable, but closer to what happens when atime is turned on. This approach has been in place for a number of years (five or six, at least) and doesn't confuse programs or unsuspecting users.

--dave

noatime and mail programs

rfunk — Thu, 09 Aug 2007 12:26:22 +0000

I'm pretty sure the noatime incompatibility with mail programs shows up only when using a single-file mailbox format (usually mbox). Yet another reason to use maildir instead.

Defer updates

addw — Thu, 09 Aug 2007 09:09:39 +0000

Part of the reason that atime causes disk traffic is that if a file is read many times (each read satisfied from cache) an atime update will be generated for each time the file is read. So you get multiple disk writes to same the inodes over and over.

Why not defer the inode updates, then you might get one set of disk writes either when the file system is unmounted or when it becomes idle or at scheduled intervals (eg every 1/2 hour). In practice many systems do not open large numbers of files, but repeatedly access a subset time and again. The usual exception to this is the backup program.

From my point of view: if the system dies before it writes the atime out then not a lot is lost; maybe a spurious ''you have mail'' when I login again.

Memory usage is the primary cost as the in-memory inode needs to be kept longer than it normally would be. This could be ameliorated by having a new strucut (device, inode#, atime) to store this info if we trash the in-memory inode.