Nervous With New Config

[JP]

I recently purchased a new 4TB drive to replace my old 2TB Parity drive and move the 2TB Parity Drive to a Data Drive.  I thought it might be simple, but my own ignorance got in the way.  I was unaware I was out of SATA ports so I had to buy an Adaptec 1430SA card.  It didn't work until I was told it needed the latest firmware.  It still didn't work until I flashed the motherboard BIOS.  However, now everything seems great.  I did a recent parity check and it did so with 0 errors.  There is only one data drive that brings up a flag in the SMART report and this is due to 166 reallocated sectors.  However, it has stood at 166 reallocated sectors for over a year now so I think it is probably fine.  I've precleared the new 4TB drive and it looks good.

 

I'm ready to take the next steps, but since I've already been ignorant about some of these preliminary steps I wanted to ask for good measure that what I hope to do as next steps is best.  I could see where I might be able to really screw up things here and although my critical data is backed up I'm still nervous about potentially having to rebuild so much if I choose the wrong option.  I've done a lot of reading on the forum and here is what I think my next steps are:

 

1.  Stop the array and make a backup copy of the CONFIG folder from the flash drive.  **DONE**

2.  Take a screenshot of where each drive currently resides (DISK1, DISK2, DISK3, etc.).  **DONE**

3.  Go to TOOLS --> NEW CONFIG and assign the parity drive to be the new 4TB drive AND using the screenshot from 2. assign all the same data drives in the same location (DISK1, DISK2, DISK3, etc.).  Assign the old 2TB Parity Drive to the last available data drive slot (DISK5 in my case).

4.  Start the array and let parity build.  Do not format the unformatted old parity disk yet and do not write to the array.

5.  Try not to panic and hope for the best.

6.  Once the parity build completes do a parity check.

7.  If the parity check completes without an issue, then and only then, format the old parity drive (now a data drive).

8.  Delete the CONFIG folder backup since you wouldn't want to use it again.

9.  Start writing to the array and relax.

 

Does this seem accurate?   

[itimpi]

The procedure you laid out would work, but not sure why you want to got the New Config route?  You can switch to the new parity drive without doing that.

[JP]

The procedure you laid out would work, but not sure why you want to got the New Config route?  You can switch to the new parity drive without doing that.

 

I had the impression the NEW CONFIG process did something simultaneously while the parity build was being completed.  Maybe that was a preclear, but I'm not sure why I would need to do a preclear on the old parity drive.  It was precleared years ago and working fine since then.

 

I almost went ahead and simply stopped the array and reassigned the parity drive to the new 4TB drive, but it gave me a big bold **WRONG** in red letters.  That scared me a little so I just stepped away.   Should I simply disregard the **WRONG** and force the array to start with the new parity drive and leave the old parity drive unassigned?  This way if something does go wrong I could simply reassign the old parity drive back...correct?

[JonathanM]

The procedure you laid out would work, but not sure why you want to got the New Config route?  You can switch to the new parity drive without doing that.

It's a more streamlined method of getting the old parity drive to be included as a data drive. He's rebuilding parity regardless, why not include the old trusted parity drive in the parity build, then format it after parity is checked good with the new drive.

[JP]

Since this seemed to make some sense I went ahead and started with the NEW CONFIG approach.  All the drives turned up green, which is good.  The parity sync has started so I'll have some time to wait.  Seems very slow at the beginning with only ~30MB/sec, but may be normal.

[JP]

Weird.  Parity sync was stuck around ~28Mb/sec for the first hour or so and now its jumped to ~105Mb/sec?  It is so early in this process I don't see that any of the drives could have completed.  Could it have been that it was struggling to read data from one particular drive, but now that it has moved past the bad or reallocated sectors it can get up to normal speeds?  All the drives are still reflecting green status.

[bonienl]

Weird.  Parity sync was stuck around ~28Mb/sec for the first hour or so and now its jumped to ~105Mb/sec?  It is so early in this process I don't see that any of the drives could have completed.  Could it have been that it was struggling to read data from one particular drive, but now that it has moved past the bad or reallocated sectors it can get up to normal speeds?  All the drives are still reflecting green status.

 

You can click on the disk icon on the main page for each disk, and it will show logging related to that disk. Might give some clues.

[JP]

Drat...now it jumped back down to ~29Mb/sec.  I looked through each disc logs, but admittedly that information might as well be written in hieroglyphics for me.  I struggle with understanding what might be abnormal.  I've attached all the disc logs in case anyone can make better sense of it than me.  I don't have a huge array, only 5 discs.

Slow_Parity_Sync-Disk_Logs.txt

[JorgeB]

I see you have one Samsung HD203WI, they don't like parity checks/syncs, see here:

 

https://lime-technology.com/forum/index.php?topic=42384.0

[JP]

I see you have one Samsung HD203WI, they don't like parity checks/syncs, see here:

 

https://lime-technology.com/forum/index.php?topic=42384.0

 

Oh my.  Not great news, but not altogether bad either.  At least it should be creating the parity sync properly if this is the issue. 

[JorgeB]

Yes, they spend some time working at 1/3 speed during parity check/sync, but normal read/wrights to the array are at full speed and they've been very reliable for me.

 

[JP]

Parity Sync appears to have completed OK.  I started a Parity Check now.  Outside of the slow sync/check speeds (probably due to the Samsung drive) the only thing that seems a little odd is that I don't have any temperature readings for the data drives or the cache drive.  Since the new parity drive was a 4TB drive it caused all the other drives to Spin Down about half-way through the parity sync because all the data drives are 2TB or 1TB.  I thought by starting the Parity Check it would sort of wake everything back up again, which it appears to have done because it is going through the check just albeit without any temp readings. 

 

I guess I'll just wait for it to finish and then do a reboot.  When a drive stops reporting temp in the past this seems to fix it.

[JorgeB]

Go to Settings > Disk Settings and set Tunable (poll_attributes) to a lower value, this is how often in seconds disks temperatures are read, default is to high, set to something like 60 or 300.

[JP]

Go to Settings > Disk Settings and set Tunable (poll_attributes) to a lower value, this is how often in seconds disks temperatures are read, default is to high, set to something like 60 or 300.

 

Thanks.  I didn't change anything and just noticed they did come back.  Looks good so far.

[JP]

Geesh... Now I'm starting to wonder if something else is going on. The parity check seems to be taking much longer than the sync and there is no fluctuation in speeds. It has stayed around 28 MB/sec for the whole check, no spikes to 100 MB/sec. 19 hours so far at 49% for the check and an estimated 1 more day to go.  No errors though so I guess I'll just let it finish.

[JorgeB]

Without any reason I could find, sometimes the disks spend about half parity check at 1/3 speed, other times almost all check, these are my 2 last parity checks on the server using these disks (I move them all to the same server so only one is affected):

 

2015/11/01 – Avg spd 66.6MB/s – 8h20m46s

2015/12/06 – Avg spd 29.8MB/s – 18h37m25s

 

So yes, it can fluctuate a lot.

 

[JP]

Without any reason I could find, sometimes the disks spend about half parity check at 1/3 speed, other times almost all check, these are my 2 last parity checks on the server using these disks (I move them all to the same server so only one is affected):

 

2015/11/01 – Avg spd 66.6MB/s – 8h20m46s

2015/12/06 – Avg spd 29.8MB/s – 18h37m25s

 

So yes, it can fluctuate a lot.

 

That is really weird. 

[JP]

So the parity check seemed to complete OK.  It still says 0 errors.  I decided to go ahead and format the old parity drive, which also seemed to go OK with one new thing I didn't exactly expect.  The newly formatted data drive (old parity drive) did so with an XFS file system.  All my other data drives are already at REISFRS.  My cache drive is BTRFS.  All this is OK...correct?

[JP]

One other weird thing I just noticed was the parity check doesn't appear to have been logged.  As you can see from the screenshot that it did complete, but on the line below it, it states that no parity checks have been completed?  Weird.

[JorgeB]

All OK, and since you have an empty drive, a good opportunity to change the remaining rfs to xfs, if you're so inclined.

[JP]

All OK, and since you have an empty drive, a good opportunity to change the remaining rfs to xfs, if you're so inclined.

 

Thanks.  What is the real benefit of xfs over rfs?  I'll have to look up the process of doing this.  Is it as simple as copying all the data from one used data drive to the blank xfs data drive, format the used data drive as XFS, and then copy all the data back to the data drive?

 

My only concern about this is I really don't understand how unRaid saves data to these drives.  If you are using shares couldn't a single file be copied on two different drives?  I worry a little that might not copy the data back to the data drives properly and mess up how the shares work.

[JorgeB]

RFS is on its way out, but for me the main benefit is array responsiveness, with RFS and almost full disks any simple operation like creating a new folder, or moving some folders would take seconds, same for initiating a copy to the array, sometimes even timing out the before the copy started.

 

It was one of the best upgrades I ever made, but if you don’t have same issues, it’s up to you, note that unless you have shares using only some disks, there’s no need to copy data back to the original disk, i.e., copy data from disk1 to empty XFS disk, format disk1 with XFS, copy data from disk2 to disk1, format disk2 and so on, much more info on the sticky thread.

 

http://lime-technology.com/forum/index.php?topic=37490.0

[gubbgnutten]

One other weird thing I just noticed was the parity check doesn't appear to have been logged.  As you can see from the screenshot that it did complete, but on the line below it, it states that no parity checks have been completed?  Weird.

 

If I recall correctly, it is a bug affecting single-digit dates.

[bonienl]

One other weird thing I just noticed was the parity check doesn't appear to have been logged.  As you can see from the screenshot that it did complete, but on the line below it, it states that no parity checks have been completed?  Weird.

 

This is a known bug, and is corrected for the upcoming version.

 

[JP]

That is great news.  A big *thanks* to everyone in this thread and on the forum who helped me!  unRaid has really worked so magnificently for me...really to the point it becomes a problem.  Given its stability I sort of just leave it for years and when it comes time for me to have a need to make changes I've either forgotten what I initially learned or the technology has lept past me.  Although I have mixed file systems now I think I'm just going to leave things as-is.  It seems to be working fine. 

 

unRaid really is just too cool.  It and Plex are the closest things to magic I know of.    Thanks again.