2

I'm trying to understand how inode access time is handled with the default "relatime" mount option in Linux, but the behavior documented in mount(8) doesn't quite match what I see. It says:

relatime

Update inode access times relative to modify or change time. Access time is only updated if the previous access time was earlier than the current modify or change time. (Similar to noatime, but doesn't break mutt or other applications that need to know if a file has been read since the last time it was modified.)

I can set up a test file with the same atime/mtime/ctime:

$ touch sometestfile
$ stat sometestfile 
  File: sometestfile
  Size: 0               Blocks: 0          IO Block: 4096   regular empty file
Device: 259,2   Inode: 38318274    Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/   user)   Gid: ( 1000/   user)
Context: unconfined_u:object_r:unlabeled_t:s0
Access: 2023-03-24 16:56:56.758033579 -0400
Modify: 2023-03-24 16:56:56.758033579 -0400
Change: 2023-03-24 16:56:56.758033579 -0400
 Birth: 2023-03-24 16:56:56.758033579 -0400

But then, a subsequent read increments atime, even though atime was not earlier than the current modify or change time:

$ cat sometestfile
$ stat sometestfile
  File: sometestfile
  Size: 0               Blocks: 0          IO Block: 4096   regular empty file
Device: 259,2   Inode: 38318274    Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/   user)   Gid: ( 1000/   user)
Context: unconfined_u:object_r:unlabeled_t:s0
Access: 2023-03-24 16:57:02.336950126 -0400
Modify: 2023-03-24 16:56:56.758033579 -0400
Change: 2023-03-24 16:56:56.758033579 -0400
 Birth: 2023-03-24 16:56:56.758033579 -0400

If I'm going by the man page, shouldn't it stay the same? Is this just a case of "<" in the man page versus "<=" in the kernel source or something? (This is basically the inverse of this question; it makes sense to me that subsequent reads don't change atime, but I'm confused as to why it changes with the first read.) I realize this is painfully nitpicky but I'm trying to wrap my head around all the edge cases involving a file's access time and just ran into this one. I see this on kernel 6.1.9 on Fedora 37 and 6.2.6 on Arch.

Improve this question

1 Answer 1

Reset to default
2

Yes, “earlier” should be “not later”.

The behaviour you see is correct. Touching the file is a write. atime is updated on the first subsequent read.

Looks like a bug in the manual.

Improve this answer
6
  • I don't know how I missed this. It is the same in my local copy of the manual. My brain just skipped over it. It autocorrected it as I read.
    – ctrl-alt-delor
    Mar 24 at 22:04
  • You're right! I'd already tried to find this in the kernel source and failed, but was finally able to track it down just now to here. Pretty sure those timespec64_compare(...) >= 0 lines must be the "not later" part. Even the comment on that function has it slightly wrong. Well, now we know.
    – epiii2
    Mar 25 at 0:17
  • 1
    I submitted github.com/util-linux/util-linux/pull/2135 and a kernel patch to fix this (I’ll add the lore link when it’s available).
    – Stephen Kitt
    Mar 25 at 8:33
  • 1
    The kernel patch is lore.kernel.org/lkml/[email protected]
    – Stephen Kitt
    Mar 25 at 17:52
  • 1
    Right, I wouldn’t want to change the behaviour, since it’s correct — if we change relatime to check strict inequality, it would result in missing atime updates in at least the first scenario (creating a new file). Both patches have been merged, the man page fix will be in the next release of util-linux (2.39, I think) and the kernel comment fixes will be in 6.4.
    – Stephen Kitt
    Apr 1 at 9:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .