Does ext4 write anything during reading with relatime?

Does ext4 write anything during reading with relatime?

[The Ghost]

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

Re: Does ext4 write anything during reading with relatime?

[Theodore Ts'o]

On Sat, Dec 05, 2015 at 02:03:14PM +0300, The Ghost wrote:
> 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).

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

Re: Does ext4 write anything during reading with relatime?

[The Ghost]

On 07/12/15 00:14, Theodore Ts'o wrote:
> On Sat, Dec 05, 2015 at 02:03:14PM +0300, The Ghost wrote:
>> 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).
>
> 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

Re: Does ext4 write anything during reading with relatime?

[Theodore Ts'o]

On Tue, Dec 08, 2015 at 12:42:21AM +0300, The Ghost wrote:
> 
> 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 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

Re: Does ext4 write anything during reading with relatime?

[The Ghost]

On 08/12/15 02:19, Theodore Ts'o wrote:
> On Tue, Dec 08, 2015 at 12:42:21AM +0300, The Ghost wrote:
>>
>> 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 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