0

According to the mount man page,

Access time is only updated if the previous access time was earlier than the current modify or change time.

However if I do this (ext4 with relatime option(*)):

> date +%T.%N ; dd if=/dev/random of=random.dat bs=1 count=4096 ; date +%T.%N ; stat random.dat 
18:52:00.616084761
4096+0 records in
4096+0 records out
4096 bytes (4.1 kB, 4.0 KiB) copied, 0.0319383 s, 128 kB/s
18:52:00.651183318
  File: random.dat
  Size: 4096            Blocks: 8          IO Block: 4096   regular file
Device: fd01h/64769d    Inode: 28313073    Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/      me)   Gid: ( 1000/      me)
Access: 2022-09-26 18:52:00.616297607 +0200
Modify: 2022-09-26 18:52:00.648297639 +0200
Change: 2022-09-26 18:52:00.648297639 +0200
 Birth: -

The access time seems to be stuck to the creation time, and if I rerun it (so now random.dat exists, and it is the same inode that is updated) I get:

> date +%T.%N ; dd if=/dev/random of=random.dat bs=1 count=4096 ; date +%T.%N ; stat random.dat 
18:52:43.014712313
4096+0 records in
4096+0 records out
4096 bytes (4.1 kB, 4.0 KiB) copied, 0.0633748 s, 64.6 kB/s
18:52:43.081174320
  File: random.dat
  Size: 4096            Blocks: 8          IO Block: 4096   regular file
Device: fd01h/64769d    Inode: 28313073    Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/      me)   Gid: ( 1000/      me)
Access: 2022-09-26 18:52:00.616297607 +0200
Modify: 2022-09-26 18:52:43.076338407 +0200
Change: 2022-09-26 18:52:43.076338407 +0200
 Birth: -

... where the access time hasn't changed at all despite a complete rewrite of the file contents.

What am I missing/misunderstanding? Shouldn't the access time be updated together with the modify and change ones?

(*) /dev/mapper/vgkubuntu-root on / type ext4 (rw,relatime,errors=remount-ro)

(**) Use of dd if=/dev/random for demo purposes (slow output)

Improve this question
5
  • You mentioned something about "creation time", where do you see that? Why should the access time change if you don't read the data? Rewriting the file's data does not access the data (note that the inode stays the same). Commented Sep 26, 2022 at 17:30
  • In the context of the three timestamps in the inode of a file, "access" means "read". Writing bytes to a file does not itself change the access timestamp (atime), only the modification timestamp (mtime). If you want to see the file's atmie update, open and read the file. This can be as simple as cat filename > /dev/null. Commented Sep 26, 2022 at 19:24
  • @Kusalananda I expect the creation time to be a few milliseconds after the output of the first date (even if there is no timestamp defined for it in ext4). Also access includes read, but what else? (otherwise why isn't it named read?). Commented Sep 26, 2022 at 19:49
  • @xenoid mmap(2) accesses the file and isn't read(2) Commented Sep 26, 2022 at 20:49
  • @xenoid the names of the timestamps were created back in the 1980s or 1970s by researchers at Bell Labs. They picked the names and behavior of the timestamps and since then Unix and Linux developers have kept the names and behaviors for backward compatibility. Why did they choose the word "access" rather than "read"? Hard to say. But the fact remains that reading the file data is what changes the timestamp named atime. Commented Sep 27, 2022 at 10:23

1 Answer 1

Reset to default
2

Since you are not accessing the data blocks (only writing to them) then atime is not updated. If you read the random.dat then the atime will get updated (as long as the relatime criteria is met).

you can see this for looking for calls to file_accessed() in the kernel:

https://github.com/torvalds/linux/blob/master/fs/ext4/file.c

file_accessed will call the routines to update atime in the inode, and is only called in the read functions (and mmap).

Improve this answer

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.