Why does parity keep runing when it has already covered the size of array disks


Recommended Posts

Hi. just replaced my 2TB parity for  4TB drive. just to be safe i did another paritycheck.

since all the disks in the array are 2TB i found its strange it would keep checking the other 2TB.

I understand that it wont be often that the paritydrive is the largest drive but it would still make sense it would finish once it had covered all data.

 

I canceled the parity check cause i did not see whar benefit it would have to let it finish.

Link to comment

If you stop the check before it finishes checking the entire 4TB, then it hasn't validated that the parity disk has all zeroes in the area beyond the size of the array disks.    If for some reason it does not, then you'll have incorrect parity when you add an array drive of that size.

 

It's true that as long as the only drive involved in the check at that point is the parity drive, stopping the check won't have any real impact -- but be sure you run a full check BEFORE you add any larger drives, just to be sure any bit errors on the parity drive are corrected before you start actually relying on that area of the drive.

 

I'd just always let the parity check run to completion  :)

Link to comment

thanks for the insights.

i thought it was just an extra safety to do an extra parity check after the new parity disk had rebuild. and before adding a new drive.

I had  just added a new 4TB data drive so the all next checks will have to be full.

i'll just do another full check now before putting any data on it.

all new drives have been precleared  3 times. so i assume i should be safe.

doing a no-correct check now to see if all is indeed fine

Link to comment

thanks for the insights.

i thought it was just an extra safety to do an extra parity check after the new parity disk had rebuild. and before adding a new drive.

I had  just added a new 4TB data drive so the all next checks will have to be full.

i'll just do another full check now before putting any data on it.

all new drives have been precleared  3 times. so i assume i should be safe.

doing a no-correct check now to see if all is indeed fine

 

Long ago I did some research on the effectiveness of burn-in on hard drives. They refer to something called the bathtub curve, where drives begin their lives with a significant % of failure, then break into a relative low % failure period, and then, as they get old, the % goes up again.

 

There is some debate as to whether the testing really helps. Some say don't test, because statistically it is insignificant. Others say test extensively. And some like me are in the middle. I like to run a preclear as a somewhat quick test and feel it is pretty effective at taking the edge off of the front end of the curve. I have found 2 that failed and got replace (both older Seagates). I also feel that buying better drives (read the reviews and Backblaze results) is a good way to avoid drive problems, and that if the drive survives one pass of preclear it is on pretty solid ground. But I am sensitive to even 1 or 2 reallocated or pending sectors. Like a pothole that grows as cars travel past it, I have found these problems just get bigger and bigger. So I will continue to test, and if after 3 or 4 preclears the reallocations don't hold steady, I return them for replacements.

Link to comment

The bathtub curve is a well-known function for virtually all electronic devices -- whether hard drives, memory, processors, etc.    Devices either fail early ("infant mortality"), or at the end of their life cycle ("wear-out" failures) ... and tend to be very reliable in-between.  Thus the shape of their reliability curve  :)

 

I concur completely at doing a thorough test of drives when you first get them.  I use WD's excellent Data Lifeguard utility to stress all new drives I get -- I do a Quick Test; then an Extended Test; then a full Write Zeroes; then repeat the Quick Test and Extended Test.  I then write at least a TB of data to it; and then do a validation of the data.    If ANYTHING goes wrong during any of those tests ... or if so much as a single sector is reallocated ... I return the drive for replacement.      If I'm going to use it in UnRAID, I then run a pre-clear cycle ... and, again, if ANYTHING changes I RMA the drive.

 

Once a drive is in use, I'm a bit less particular ... I'll accept a few reallocations (that is, after all, what the spare sectors are for) ... but if they start to "grow" in number, I take the drive out of service;  reformat it; and use it for backups.  At least half of my backup drives are drives I've either taken out for this reason; or drives that I've simply replaced with larger ones in my server or a desktop.

 

 

Link to comment

The blackblaze report was indeed why i chose this time for the hitachi nas drives. Altho the particular (now HGST) drive was not part of the test itself the positive result of hittachis in general was motivating enough. For the same reason i chose not to go for the faster 1tb/platter seagate drives. When reading through new egg reviews it is shocking how high the initial failure of most current drives is. When reading reviews however i always take into account than someone with a negative experience is far more likely to report than someone who has no problems. I also wonder how much transport could have to do with this.

 

I did have one weird thing with the drives which i reported in this thread with preclear taking longer than expected. A couple of post down are also the preclear reports.

http://lime-technology.com/forum/index.php?topic=4068.msg298196#msg298196

 

During the current parity check the drive speeds seem fine.

2.91 TB (73%) Estimated speed: 115.73 MB/sec

Link to comment

Speed of your parity check looks fine.  From what I've read, the HGST NAS units are VERY good drives.

They'll likely be slightly slower than the Seagate NAS units, since the platter density is lower ... but you should still get very good transfer rates.

... and hopefully superb reliability  :)

Link to comment

Speed of your parity check looks fine.  From what I've read, the HGST NAS units are VERY good drives.

They'll likely be slightly slower than the Seagate NAS units, since the platter density is lower ... but you should still get very good transfer rates.

... and hopefully superb reliability  :)

 

I agree. All but 2 disks in my array are Hitachi. They are by far my favs. I ventured into the Seagates only because of the Backblaze report. Hope they hold up as well.

Link to comment

I'll have to try them next time.

 

In the last year, I've built one with all WD Red 3TB's;  one with all Seagate 4TB NAS units; and 2 with all 4TB WD Reds.    All are still rock-solid ... but it'd be interesting to see how the Hitachi's compare.  The only downside to them is both the WD's and the Seagate's are 1TB/platter units, whereas the Hitachi's are only 800GB/platter, so there's a bit of a speed sacrifice.

 

Link to comment

Speed of your parity check looks fine.  From what I've read, the HGST NAS units are VERY good drives.

They'll likely be slightly slower than the Seagate NAS units, since the platter density is lower ... but you should still get very good transfer rates.

... and hopefully superb reliability  :)

ye there must have been some anomaly why the preread during preclear took like 17 hours even tho the speeds reported during the preclearing looked normal (150-80 MB/s)

 

== Using :Read block size = 65536 Bytes
== Last Cycle's Pre Read Time  : 17:19:24 (64 MB/s)
== Last Cycle's Zeroing time   : 8:53:51 (124 MB/s)
== Last Cycle's Post Read Time : 28:02:02 (39 MB/s)
== Last Cycle's Total Time     : 36:57:06

 

i think it will remain a mystery to me

 

the HGST NAS drives are 7200rpm which might make up A little for onlu haveing 800gb platters compared to models that have 1TB platters and spin at lower speeds

 

I ventured into the Seagates only because of the Backblaze report. Hope they hold up as well.

seagates did have the highest failure rate in the Backblaze report. maybe it was mostly the older seagates that failed I don't remember the full article at this point.

do remember they were currently buying 4tb seagates and wd reds.

 

 

Link to comment

the HGST NAS drives are 7200rpm which might make up A little for onlu haveing 800gb platters compared to models that have 1TB platters and spin at lower speeds

 

Yes, the 7200rpm speed helps - in fact, it makes the HGST units slightly faster than WD Reds, but still slightly slower than the Seagate NAS units (which spin faster than the Reds).  The tradeoff, of course, is that they have to spin faster, thus drawing a bit more power and generating a bit more heat.    But this is very marginal ... nothing I'd be concerned with ... and indeed the higher rpm also means they have slightly better access times than the other units.

 

Link to comment

I ventured into the Seagates only because of the Backblaze report. Hope they hold up as well.

seagates did have the highest failure rate in the Backblaze report. maybe it was mostly the older seagates that failed I don't remember the full article at this point.

do remember they were currently buying 4tb seagates and wd reds.

 

Yes, I have avoided Seagate's like the plague. Their 2T offerings were awful. But the BackBlaze study gave one 4T drive in particular high marks - model ST4000DM000. Not quite as reliable as Hitachi but at much lower price. That's the one I bought. So far so good!

Link to comment

the hgst nas drives were only €150 here  compared to €135 for the ST4000DM000 so it was a small premium

tho its always good to spread out the risk anyway. that's the beauty of unraid compared to normal raid. expand when you want and also the drive does not need to be the same spec as the other drives.

 

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.