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
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
