Trying to upgrade from dual 3tb parity to dual 14tb but at drive limit

[danimal86]

16 hours ago, itimpi said:

That is quite normal for the speed to go down as one moves towards the inner tracks.   Drives spin at a constant speed,  so because the outer tracks are physically longer they can hold more sectors and the resulting speed is higher.

is it normal for the second parity drive rebuild to go slower than the first?

[JonathanM]

It should speed up when it passes the 3TB mark, right now it's hitting all the drives as it's below the 2TB line.

[danimal86]

1 hour ago, JonathanM said:

It should speed up when it passes the 3TB mark, right now it's hitting all the drives as it's below the 2TB line.

Ok,  thats good to know.  Its going slower and slower as time goes.  Hopefully it will speed up in after it passes that 3tb

[ChatNoir]

57 minutes ago, danimal86 said:

Hopefully it will speed up in after it passes that 3tb

 

As JonathanM mentioned, it should.

 

The speed on my last check were like that (18TB parity and one Data drive, several 14TB and two 6TB):

 

Ignore the drops, I was probably writing stuff on the Array. I showed in green, the theoretical behavior without me messing things up.

[danimal86]

13 minutes ago, ChatNoir said:

 

As JonathanM mentioned, it should.

 

The speed on my last check were like that (18TB parity and one Data drive, several 14TB and two 6TB):

 

Ignore the drops, I was probably writing stuff on the Array. I showed in green, the theoretical behavior without me messing things up.

Sweet graph.  is that a plugin?

 

[ChatNoir]

Just now, danimal86 said:

is that a plugin?

Several docker containers:

 

[danimal86]

4 hours ago, ChatNoir said:

 

As JonathanM mentioned, it should.

 

The speed on my last check were like that (18TB parity and one Data drive, several 14TB and two 6TB):

 

Ignore the drops, I was probably writing stuff on the Array. I showed in green, the theoretical behavior without me messing things up.

well its back up to over 200mb/s.

Really interesting how on the first parity rebuild, it want fast to slow.....on the second it went slow to fast.  

Edited November 3, 2021 by danimal86

[itimpi]

19 minutes ago, danimal86 said:

Really interesting how on the first parity rebuild, it want fast to slow.....on the second it went slow to fast.  

It probably depended exactly when you looked at the speed  

 

At any point the speed is determined by the slowest drive currently active.  With multiple drive sizes you will see it slowing down as a particular size of drive gets to its inner tracks, and then jumping up again when the build gets past the size of that drive and the next drive size becomes the limiting factor.  This pattern can repeat for each drive size.

[danimal86]

On 11/2/2021 at 10:46 AM, JonathanM said:

You should do a parity check after the parity build on the new drives, just as a confidence check.

About 2.5hrs left to go and then i'll be doing a parity check before starting to swap drives.  

 

Anything on the parity check that i should look for, or just see if it say "completed with zero errors"?

[JonathanM]

30 minutes ago, danimal86 said:

About 2.5hrs left to go and then i'll be doing a parity check before starting to swap drives.  

 

Anything on the parity check that i should look for, or just see if it say "completed with zero errors"?

zero errors = good to go. any other result, investigate.

[danimal86]

10 minutes ago, JonathanM said:

zero errors = good to go. any other result, investigate.

Sounds good.  

Is the parity check going to take the same amount of time as the rebuild?

[JonathanM]

1 minute ago, danimal86 said:

Sounds good.  

Is the parity check going to take the same amount of time as the rebuild?

Roughly.

[danimal86]

12 minutes ago, JonathanM said:

Roughly.

Dang, this is a long process!  Ha.

 

When i do the rebuild of the data drives, since its only writing around 1.25tb to each drive, that should go quicker? or will it take as long as the parity rebuild?

[JonathanM]

6 minutes ago, danimal86 said:

Dang, this is a long process!  Ha.

 

When i do the rebuild of the data drives, since its only writing around 1.25tb to each drive, that should go quicker? or will it take as long as the parity rebuild?

Parity doesn't work with files, but complete filesystems.

The entire drive capacity must be written.

[danimal86]

1 hour ago, JonathanM said:

Parity doesn't work with files, but complete filesystems.

The entire drive capacity must be written.

Second parity rebuild is done.  

 

I've never forced a manual parity check outside of the normal monthly automatic parity check and haven't noticed the little "write corrections to parity"

What does it do?  Keep it checked?

 

[JonathanM]

Parity check reads all the data drives, does the parity calculation, reads the parity drives and compares. If it's correct, it moves on to the next sector. If it's wrong, parity errors are incremented, and depending on the write corrections setting, it either leaves the error as is, or writes the calculated value back to the parity disks.

 

Normally you don't want writes to happen unless you know WHY it's wrong to begin with. For example, after a forced shutdown where writes to the data drives were occurring, parity errors are somewhat expected because the data writes are committed first and parity may not have had a chance to complete.

 

Under typical operation you should NEVER have parity errors, so finding out why ( bad cable, bad RAM, etc, etc) and fixing the root cause before committing the writes is the prudent thing to do.

 

So, normal routine parity checks, NON-correcting, if parity errors are found, figure out a plausible explanation and correct the issue, including any file system corruption, then do a parity check with write corrections, typically followed up by a non-correcting check to be sure whatever was wrong is now fixed.

 

Zero parity errors is the only acceptable outcome. Any errors means a failed drive will be reconstructed with the wrong bits.

[itimpi]

8 minutes ago, danimal86 said:

What does it do?  Keep it checked?

It is normally recommended to NOT leave it checked.    
 

With it checked then if any discrepancy is noticed between the data drives and the parity drive then the parity is automatically updated to match the data drives.    The downside is that if you unknowingly have a data drive playing up this can end up corrupting parity which means if a data drive later fails you might have data corruption when you try and rebuild it.

 

I normally recommend that you only do a correcting check from a parity check you start manually when you have some reason to think that parity might not be valid and have already corrected the issue that made you think parity might be invalid.

[danimal86]

4 minutes ago, JonathanM said:

Parity check reads all the data drives, does the parity calculation, reads the parity drives and compares. If it's correct, it moves on to the next sector. If it's wrong, parity errors are incremented, and depending on the write corrections setting, it either leaves the error as is, or writes the calculated value back to the parity disks.

 

Normally you don't want writes to happen unless you know WHY it's wrong to begin with. For example, after a forced shutdown where writes to the data drives were occurring, parity errors are somewhat expected because the data writes are committed first and parity may not have had a chance to complete.

 

Under typical operation you should NEVER have parity errors, so finding out why ( bad cable, bad RAM, etc, etc) and fixing the root cause before committing the writes is the prudent thing to do.

 

So, normal routine parity checks, NON-correcting, if parity errors are found, figure out a plausible explanation and correct the issue, including any file system corruption, then do a parity check with write corrections, typically followed up by a non-correcting check to be sure whatever was wrong is now fixed.

 

Zero parity errors is the only acceptable outcome. Any errors means a failed drive will be reconstructed with the wrong bits.

 

2 minutes ago, itimpi said:

It is normally recommended to NOT leave it checked.    
 

With it checked then if any discrepancy is noticed between the data drives and the parity drive then the parity is automatically updated to match the data drives.    The downside is that if you unknowingly have a data drive playing up this can end up corrupting parity which means if a data drive later fails you might have data corruption when you try and rebuild it.

 

I normally recommend that you only do a correcting check from a parity check you start manually when you have some reason to think that parity might not be valid and have already corrected the issue that made you think parity might be invalid.

Thanks for explaining this. 

 

I unchecked it and started a check, I also just checked under my scheduler settings and it was set to write corrections by default, i went ahead and set it to No now. 

 

i went back and looked at my parity check history and it shows 0 errors going back as far as April of 2020 (thats as far as it shows and i have it set to check the 1st of the month)

 

 

[danimal86]

Well the parity check after both parity drives were swapped is done and completed with 0 errors.  Looks like its time to start to swap drives. 

 

will the data drive rebuilds take just as long as the parity drives?  The drives im replacing only have 1.25tb's on them.

 

[trurl]

24 minutes ago, danimal86 said:

will the data drive rebuilds take just as long as the parity drives?  The drives im replacing only have 1.25tb's on them.

Rebuilds always write the complete disk being rebuilt. Parity doesn't know anything about files and how full your disks are. It is all just bits, and all of the bits to the end of the disk are written for rebuild.

[danimal86]

20 minutes ago, trurl said:

Rebuilds always write the complete disk being rebuilt. Parity doesn't know anything about files and how full your disks are. It is all just bits, and all of the bits to the end of the disk are written for rebuild.

Bummer!  Ohh well, another 28hrs of rebuild

 

[trurl]

How could it be otherwise? All the bits of every disk must be in sync with parity. All the bits of all disks are required to rebuild a missing disk. If you had a data disk that only had a few files on it, and that whole disk wasn't completely in sync with parity, then how could it be used to rebuild another data disk that was completely full of files?

[danimal86]

9 minutes ago, trurl said:

How could it be otherwise? All the bits of every disk must be in sync with parity. All the bits of all disks are required to rebuild a missing disk. If you had a data disk that only had a few files on it, and that whole disk wasn't completely in sync with parity, then how could it be used to rebuild another data disk that was completely full of files?

i guess i dont really have all the knowledge of how unriad and the parity works (i guess that's what i'm here for) 

 

my old thinking is that, the drive im replacing only has 1tb of data on it, it would only write 1tb of data to the new drive.  Sound like i've got some learning to do. 🙂

[trurl]

54 minutes ago, danimal86 said:

how unriad and the parity works

 

https://wiki.unraid.net/Manual/Overview#Parity-Protected_Array

[trurl]

10 hours ago, danimal86 said:

my old thinking is that, the drive im replacing only has 1tb of data on it, it would only write 1tb of data to the new drive.

Parity doesn't know or care about files, and doesn't have any of your data. As far as parity is concerned, the whole disk is full of bits and every bit of every disk must be in sync with parity because every bit of every disk is needed for the parity calculation to rebuild a missing disk.

 

The link I gave does a pretty good job of explaining how parity works. It is very simple, and is basically the same idea wherever it is used in computers and communication; with other RAID systems, with data transmission, etc. Parity is just an extra bit that allows a missing bit to be calculated from all the other bits.