Does ext4 write anything during reading with relatime?

When mounted read-only, naturally, reading from an ext4 filesystem does not cause any write operations. But if I mount it read-write and try to read from it, then apparently some write operations are issued, because my "write-mostly" drive in a RAID1 array spins up. Now, I understand that apparently the mount operation itself does write something, and I do mount it with a "relatime" option, but I'm just reading stuff over and over again - it shouldn't be caused by atime updating. Also, a bug with "write-mostly" finally got fixed, and I'm using a fixed kernel (latest 3.16 from Debian Jessie-backports).

I just want someone to explain what's happening or direct me towards some information about that, because I just want to understand. :) And I don't know any means to find out myself... if there are any, those would require much better understanding of filesystems than I have...

The Ghost

Relatime doesn't guarantee that there will be _no_ atime updates. You would need to mount with noatime if you want to guarantee that there will be zero atime updates.

Relatime will update atime if the file is accessed and the atime is older than 24 hours. This guarantees that atime is up to date to approximately a day, so you can tell if a file has been accessed recently. This is useful for any system administrators.

But it does mean there will still be quite a bit of atime updates --- especially since atime updates apply to directories as much as files. Hence, if you haven't mounted the file system in 24 hours, and then you run a find operation on the entire file system, the atime for every single directory on the file system will need to be updated.

Cheers,

- Ted

I know that "relatime" does not guarantee there will be *no* atime updates. I know that it updates atime for both files and directories if it's older than the last time they have been modified. I did not know that it also updates atime if the last atime is older than 24 hours; that would indeed render my idea useless. However, what I meant is that I create a test array, make an ext4 filesystem on it, put some files there (actually, just one file about few hundred megabytes large), read them to update the atime, and then spin the disks down and *immediately* try to read them again. I did not wait for 24 hours for this test! And both drives spin up again, which means there was some write operation. Because it does not spin up when mounted read-only, nor when I read from the md device itself.

I just tried again. With relatime or noatime, the second drive spins up. Always. With read-only, it never spins up. And that doesn't make sense...

The Ghost

The superblock *does* get modified at mount time to update the last mount time and the mount count in the superblock. But I've tested using blktrace, and that's the only write I see after copying in a set of test files, reading them (so that atime > mtime), and then umounting the file system. I then started the blktrace, mounted the file system, and read all of the files using "tar cvzf /tmp/foo.tar.gz /mnt".

Cheers,

- Ted

During mount, yes, of course. During unmount, too. But, I spin the drives down after I've mounted them and updated the atimes!..

blktrace? thanks for the tip. :) I've installed it, and here is what I see.

I am too lazy to go plug in the drives I used for the RAID, so I just set up a loop device and do the test. I set up blktrace to register write requests, and for some reason, it shows 1 event each launch (this is probably the way it's supposed to be, though I have no idea what it means). Fine. I do the test, and it's only that one request, so you're right - nothing else gets written.

But then, why does my second drive spin up?! I've plugged in my RAID drives, and did the test again. And it did show 5 write events, 1 KiB data!! Plus that "one usual event" which, for some reason, does not cause the second drive to spin up. So, it does write something only if we're using an md device! But not if we're using a loop device, or whatever device you've used for the test.

Now I'm getting a feeling I probably won't find out what mysterious data gets written onto an md device and not any other kind of device, and even if I do, I probably wouldn't understand it...

This leads us to a conclusion that it's not the filesystem's fault - it's probably the RAID. But, it does not happen when I mount the filesystem in read-only mode, or when I read from the md device itself, which led me to believe it must be the filesystem!!..

Thank you for taking your time to explore this mystery with me. :) Now I can boast that not only have I contributed to the Linux kernel development by helping get one patch accepted, but also I've talked to Ted Ts'o once about something that apparently turned out to have nothing to do with ext4. :)

The Ghost