After upgrade to unraid 4.4 weeks ago today i start monthly parity check and found some interesting data in disk status. As you can see from attached screen shot. there are two disks showing far less read counts compared with others in same disk size or larger size. I thought during parity check, data have to be read from each data disk and XORed to against data in parity disk. So why this two particular disks have less read counts? FWIW, this two disks happened to be IDE disks and others are all SATA.

 

comments?

 

 

then again, why is disk 8 reading so much higher? 

 

then again, why is disk 8 reading so much higher? 

 

 

If parity check is block by block checking then all disk should have about the same read counts as the parity disk has since i start parity check right after i power on my system.

These two with lower counts really puzzled me.

It is a bit of a mystery, but I do not think that there is anything wrong with your system.

 

unRAID 4.4+ counts I/Os differently than earlier versions.  The newer technique uses OS level read and write counts, while the older version used unRAID maintained counts.  I can't explain why the counts are different for different drives, unless perhaps you read some of the other disks before / during the parity check?

 

Let the parity check complete.

I'm also running 4.4 unRAID.

 

All I can think of is the different drivers bufer the I/O requests differently.  Physical "reads" and "writes" to the disks are very different than logical ones.

 

As an experiment, I just "Cleared Statistics" then pressed the button to initiate a Parity check.   I have three SATA drives and eight IDE drives in my array,

 

In theory, there should be an equal number of "Reads" on all the drives.

 

The IDE drives are all roughly equal to each other (but not exactly equal)  and the three SATA drives are also roughly equal to each other (and also not exactly equal)

 

Now, I can understand if the number are not exactly equal, as between the time it takes unRAID to read the disk statistics of the first disk in the array to the last, many more blocks are read from the disks.  But... I've canceled the parity check and the numbers are still very different from disk to disk.

 

However, there are a LOT mode "reads" of data from the three SATA drives than the IDE drives  (parity, disk8, and disk11 are SATA drives).   

 

At this moment, 2.5% into the parity check, I cancel the parity check... the "read" statistics look like this:

parity 72,384

disk1  56,228

disk2  56,108

disk3  54,606

disk4  54,580

disk5  54,468

disk6  51,254

disk7  52,926

disk8  72,625

disk9   not installed

disk10 54,158

disk11 72,514

 

Interesting, isn't it.  Apparently, some "reads" are being satisfied by the disk buffer cache and not needing to go to the physical disk.  It is also apparent the SATA drives have almost a third more "reads" than the IDE drives.  My "read-ahead" buffer is set to 2048 on all my disks using blockdev --setra 2048..

 

Slight differences might be accounted by a script I have that keeps the directory inodes in the buffer cache by doing a periodic "ls" of my "Movies" folders. It is the only other activity on the server.   The large difference between SATA and IDE drives has to be driver related, related to their corresponding  disk buffer cache handling.

 

Joe L.

Interesting, isn't it.  Apparently, some "reads" are being satisfied by the disk buffer cache and not needing to go to the physical disk.  It is also apparent the SATA drives have almost a third more "reads" than the IDE drives.  My "read-ahead" buffer is set to 2048 on all my disks using blockdev --setra 2048..

Joe L.

 

Is there a way to force a full flush of the disk cache before you start a parity check? I know having the data in the cache means the disk was read fairly recently, but I would be more comfortable knowing it actually checked the data at the point in time that I asked it to, not just that it was ok some time in the not too distant past.

 

Having been bitten in the past by a failing disk corrupting parity during a parity check, I'm leary of the whole process. I would rather have a way to check the disks without writing changes until I know WHY it changed, or have a chance to do backups.

Is there a way to force a full flush of the disk cache before you start a parity check?

As far as I know, best you can do is type

sync

 

It should spin up all the drives and flush anything in the cash to the disks.

 

Joe L.

I know that will commit any pending writes, but the read cache is what I think I want to empty. Does the SYNC command do that as well?

I know that will commit any pending writes, but the read cache is what I think I want to empty. Does the SYNC command do that as well?

Oops.. you are correct...

 

see here: http://linux-mm.org/Drop_Caches

 

Do a "sync" first, as described to flush any blocks pending write.

 

Then type:

echo 3  >/proc/sys/vm/drop_caches

Will clear all the fs cache.