Using 4.4.2, I sometimes see differences in the statistics displayed by emhttp, compared to the states from /proc/mdcmd.

 

In particular, if I use dd to read a random block from /dev/sdX to spin up the drive, emhttp will show a read for the drive, but /proc/mdcmd will not.

 

I think I know why this is, but I just wanted to throw it out there.  I've not tried it on other versions.

 

Using 4.4.2, I sometimes see differences in the statistics displayed by emhttp, compared to the states from /proc/mdcmd.

 

In particular, if I use dd to read a random block from /dev/sdX to spin up the drive, emhttp will show a read for the drive, but /proc/mdcmd will not.

 

I think I know why this is, but I just wanted to throw it out there.  I've not tried it on other versions.

 

emhttp is now looking at the raw I/O statistics for the devices under /sys.  In /proc/md (I think) you see the buffered writes.  Because the block sizes differ, the numbers may, or may not match up.  If the data is still in the buffer cache, in memory, you won't see the change in the /proc/mdcmd output until the blocks are flushed to the disk.

 

Type

sync

to flush the buffers to the physical disks and see if /proc/mdcmd updates.  My guess is that it will.

 

Joe L.

but he did a read, not a write 

 

but he did a read, not a write 

 

True, but the block being read *might* have been in the buffer cache.. and therefore never reached the "md" driver to be read from the physical disk. ( I know he said he read a random block... but it is *possible* it was in the buffer cache )  Clearly, more testing is needed to figure out what is going on..  It sure looks like the "md" device is incrementing a "device->reads" counter for every "read" but who knows when the /proc/mdcmd value is updated.

 

Joe L.

 

 

I tested it several times, and after clean boot, and after clearing buffers (echo 3 > /proc/sys/vm/drop_caches).

 

I can understand what it happening since the dd read is to the raw device, which is below the MD level.  The results are completely expected once you think about it.  I just wanted to make others aware of it who may not have anticipated it.

 

This came up when I was working on the new interface, and comparing data to the original emhttp interface and found discrepancies.

<embarrassed>

I completely missed that he was reading from /dev/sdX...  and not from the /dev/mdX device.  That makes a HUGE difference.

</embarrassed>

No way the md device can know when you went behind its back to perform the read on the underlying device.

 

Joe L.

BTW, it is not always that emhttp has larger numbers than mdcmd, and it is not limited to reads.

 

I reset stats last night, and today both reads and writes are out of sync (all are larger read from mdcmd than reported in emhttp).  This may very well be due to buffers however.