Since the parity check is important to the health and wellfare of the unRaid array I would like a chunky scheduled parity check.

What I mean by chunky is some fraction of the drive checked by some schedule.

For example parity check 1/4 of my array every week on sunday at midnight.

This would help reduce the time when the array is sluggish and still preserve the integrety of the array.

 

 

 

 

For most users, parity checks take <10 hours and can be started in the evening and be complete or almost compllete by morning.

 

Users that have lots of PCI based drives will find that the parity checks take longer to run.  I have not heard of anyone to date reporting a parity check taking more than maybe 15 hours.

 

This doesn't seem like a huge problem now, but if 2T - 4T drives start to be commonplace, parity check times could certainly get pretty long.

With 15 x 1To drives and 2 promise PCI sata card (7 drives), it would have taken around 18 hours to complete, even if i never could make it work, i had to go down to 12 drives. I then remember 15 hours with 12, but not sure of this as i only did it once

 

This means more than a full day when the 1.5To drive will ship 

This would be great.

 

I'd take it even one step further.  Set it up to where when unraid is idle, do low priority parity checks in the background.  Should make manual parity checks unecessary. 

I'd take it even one step further.  Set it up to where when unraid is idle, do low priority parity checks in the background.  Should make manual parity checks unecessary. 

 

This sounds very good. Count me in for this feature request.

 

Thanks

Harald

 

I like this idea. IMO all drives should only ever be spun up on parity creation or repair. In all other instances a fraction of drives should up up at one time and not all.

To check parity, all drives have to be spun up.... so you would take an "idle" machine, spin up all the drives, to use the idle time for a parity check chunk?  Doesn't sound very desirable to me.

 

What would be better, is the standard scheduled parity check, but monitor disk I/O that was *not* from the parity check process, and sleep the parity check immediately when other disk I/O is detected.... and require some minimum amount of disk idle time before parity check starts back up.

 

Copernic desktop search indexing process works similar to this.

I like bubbaQ's idea. That way a parity check would never slow the machine down. At least that we would notice.

To check parity, all drives have to be spun up.... so you would take an "idle" machine, spin up all the drives, to use the idle time for a parity check chunk?  Doesn't sound very desirable to me.

 

What would be better, is the standard scheduled parity check, but monitor disk I/O that was *not* from the parity check process, and sleep the parity check immediately when other disk I/O is detected.... and require some minimum amount of disk idle time before parity check starts back up.

 

Copernic desktop search indexing process works similar to this.

Excellent idea.    Might even be accomplished by reducing the "nice" on the parity check thread. (it would then be lower in priority than anything else)  It would take longer if other things were going on, but who cares... the other activities are probably more important (watching a movie, etc)

 

Joe L.

Nice and priority won't help, because the process is not CPU bound but disk I/O bound.  Even the magic "disk priority " grail would not help here because of the unique confluence of streaming media with a disk-intensive background process.

 

You have to monitor disk I/O for all processes and the parity check process, compare them several times a second, and immediately sleep the parity check process when other disk I/O is detected, and not let it wake up until you have had an appropriate period (say 5 min) of no disk I/O.

Bah think i woke up after a night sleeping on the silly stick. Obviously all drives need to be spun up to check parity. Doesnt mean you have to check the entire array every time though. There are scenarios where more frequent lesser checks may be more beneficial than one multihour disk bashing all-in-one session (assuming several lesser checks eventually = a complete check).