1

I've taken the following stats from /proc/diskstats:

9       0 md0 106989 0 _2923830_ 0 117988 0 _3448953_ 0 0 0 0
8       0 sda 33840 22299 _1143351_ 871132 87336 194804 _2003961_ 2201868 0 949992 3075508
8      32 sdc 34326 22412 _1147488_ 530856 85645 193714 _1981641_ 1147288 0 777236 1679364
8      16 sdb 34090 22044 _1145348_ 516996 87908 194091 _2002553_ 1160088 0 777432 1678168
253       0 dm-0 61416 0 _1474562_ 1089052 8671 0 _71664_ 2314824 0 152296 3403896
253       1 dm-1 16733 0 _321034_ 177216 39437 0 _1292056_ 2234284 0 366448 2411516
253       2 dm-2 27407 0 _1103562_ 301084 57436 0 _1918752_ 3595356 0 495024 3896452
253       3 dm-3 1223 0 _22904_ 16800 5373 0 _166481_ 537476 0 101444 554276

md0 is a RAID5 device with sda3, sdb3 and sdc3. dm-0, dm-1, dm-2 and dm-3 are /, /home, /var and squid-cache. Kernel 3.17-1-amd64, Debian sid.

Except dm-0, why are always more written sectors than readed? (both highlighted; 8 hours uptime)

Another machine (kernel 3.13.0-42-generic, LinuxMint 17.1):

8       0 sda 348838 182021 _14285981_ 3994572 2220600 1291157 _179318400_ 150821584 0 6850872 154817944

Another one (kernel 3.11-1-amd64, Debian wheezy:

8      16 sdb 5759214 809293 _345212787_ 20363500 6136587 7332680 528239577 _419346280_ 0 34343932 439745468

The last one (RAID1, kernel 3.2.0-4-amd64, Debian wheezy):

9       0 md0 18465 0 _765758_ 0 1471467 0 _17892758_ 0 0 0 0
8       0 sda 127945 54619 _15162313_ 1237028 1342374 3413939 _41328777_ 35251952 0 9247532 36501996
8      16 sdb 123240 48371 _14849663_ 1225468 1342456 3413948 _41328777_ 35337212 0 9281520 36573484

There is really more writes than reads or I'm missing something?

Improve this question
4
  • Checked /sys/block/sdx/stat too? Maybe helpful kernel.org/doc/Documentation/iostats.txt
    – Xen2050
    Feb 6, 2015 at 18:51
  • /sys/block/sdx/stat gives the same. I did read iostats.txt and text file procfs-diskstats. I'm looking at the fields representing sectors read and written sectors. In the same physical device, partition and logical device, the written sectors are higher than the read sectors. That seems to be non-sense. This happens even without using the system. Filesystems are ext4 with 'relatime'.
    – Emilio Lazo
    Feb 7, 2015 at 6:17
  • I try to use noatime to avoid extra writes...
    – Xen2050
    Feb 7, 2015 at 6:25
  • I did remount them on the fly with noatime some hours ago and the increase on read/written sectors were at the same ratio. Now I'll reboot and mount all involved filesystems with noatime to be sure. Later I will post the results. Thanks!
    – Emilio Lazo
    Feb 7, 2015 at 6:45

2 Answers 2

Reset to default
0

This is a good place to review:

http://www.linuxquestions.org/questions/suse-novell-60/interpreting-proc-diskstats-360350/

And for a md0 RAID1 mirror, there will always generally be more writes because it needs to write all data twice and read once. Whichever device reads the data first :)

That's the concept of using a mirror to spread the data around in case of a device failure.

cheers!

Improve this answer
1
  • Thanks! but I've read it yet. When md0 is RAID1 written sectors are the same on both physical devices but they are more than the read sectors comparing in the same device (physical, partition, md or logical dm). With RAID5 the situation is similar: dm devices shows more writes than reads; their underlying devices (e.g. md0) behaves the same way (much more writes), and again their underlying devices (e.g. sda2 and sdb2) also behaves this way, and of course sd{a,b}. I'm not considering something crucial or this is a kernel bug? All involved filesystems are ext4 with relatime or noatime. Cheers.
    – Emilio Lazo
    Feb 7, 2015 at 6:28
0

Just thought that your disk read cache (in ram) might be doing a very good job of keeping often read files in ram, leaving only the disk writes to actually use the disk.

If you have lots of ram available, and aren't routinely reading a lot of new data from the hard drive, the ram cache could be replacing a LOT of potential disk reads.

And the before-mentioned mount option noatime could avoid extra writes too, if you're not using "mutt or other applications that need to know if a file has been read since the last time it was modified."

Improve this answer
2
  • Also with noatime we have basically the same. Indeed, with 8GB I can appreciate every time how using RAM as disk read cache really increases performance, so I think this is the reason! Can be disabled the disk read cache? Would be useful for me to take new measures and see how much read stats are increased. I did look at procfs options without success. I don't want to fill all the RAM with a file in a tmpfs. Thanks!!
    – Emilio Lazo
    Feb 7, 2015 at 16:19
  • I read about a way to clear the disk cache, involved writing 1-3 to /proc/sys/vm/drop_caches, was described here and also has "vfs_cache_pressure" but it doesn't sound like an "on/off" switch... I'm sure a web search will be fruitful
    – Xen2050
    Feb 7, 2015 at 16:59

You must log in to answer this question.

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