I thought I could unassign a drive then assign a new (precleared) drive in its place and then unraid would rebuild parity and copy the contents of the formerly suspect drive to the new drive.  It's rebuilding parity but I dont think its adding any new files to the new drive.  Did I misunderstand this?

 

I am not worried about losing data. I have the suspect drive in unassigned devices and if necessary I can rsync the data to the new drive.  I just want to better understand what the parity sync/data rebuild it currently doing. 

 

Should I let it finish or should I just start an rsync to copy the data from sdj to disk 8?

 

It's not rebuilding parity => it's rebuilding the drive you replaced.    Just let it finish.

 

Ok.  thats what I wanted to happen.  But is it normal for the files that were on the suspect disk to be missing from the array?  I would have expected them to be emulated.  Also disk 8 is not increasing ion size.  Is that normal?  

The contents of the drive should indeed be emulated.   Looking more closely at your display, drive 8 is almost entirely free -- it shows 7.99TB free with only 13GB in use.    Not sure what you did, but at some point you either formatted your old drive (BAD -- if that's the case all of the data is missing); or you somehow formatted the new drive before invoking the rebuild (not sure how you could have done this).     In any event, it IS "rebuilding" drive 8 ... but as you've already noted, that drive doesn't have anything on it.    At this point you may as well let it finish -- otherwise you'll need to do a New Config and let it do a new parity sync.

 

When it's done, you'll need to copy the data from your old drive to the array.

 

 

Yep.  I definitely screwed up.  When it first started the rebuild, the drive said unmountable.  For some reason I thought that meant I should format it.  Anyway.  Fortunately the suspect drive is in tact, I will copy it to the array when the parity build it done.

That certainly explains it => the drive wasn't mountable because it didn't have a file system on it.   If you'd simply let it do the rebuild, all would have been well when it completed.    Fortunately you still have the original drive; and HOPEFULLY it's completely readable so you can copy the data back to the array.   You indicated it was a "... suspect drive ...", so I assume there may be some doubt about that -- but perhaps you just meant it had some failing SMART parameters.    In any event, if it does fail, you can always copy the data back from your backups

For some reason the "rebuild" slowed to a crawl overnight.  See attached.  

 

Would I do any harm if I stopped the array and put the suspect disk back?  Either by putting it back in its original slot 8 or simply by expanding the array?  

 

My original intention was to copy the contents of the suspect disk (sdj) to the replacement disk (now disk 8).  Given this really slow rebuild, I wonder if I am better off losing parity (there is none currently) and starting over with the suspect disk back in the array.  

 

BTW.. the disk is only suspect because of 4 reported uncorrect see below.

 

#	Attribute Name	Flag	Value	Worst	Threshold	Type	Updated	Failed	Raw Value
1	Raw read error rate	0x000f	118	099	006	Pre-fail	Always	Never	168246480
3	Spin up time	0x0003	090	090	000	Pre-fail	Always	Never	0
4	Start stop count	0x0032	100	100	020	Old age	Always	Never	13
5	Reallocated sector count	0x0033	100	100	010	Pre-fail	Always	Never	0
7	Seek error rate	0x000f	078	060	030	Pre-fail	Always	Never	64769624
9	Power on hours	0x0032	097	097	000	Old age	Always	Never	3236 (4m, 11d, 20h)
10	Spin retry count	0x0013	100	100	097	Pre-fail	Always	Never	0
12	Power cycle count	0x0032	100	100	020	Old age	Always	Never	9
183	Runtime bad block	0x0032	100	100	000	Old age	Always	Never	0
184	End-to-end error	0x0032	100	100	099	Old age	Always	Never	0
187	Reported uncorrect	0x0032	096	096	000	Old age	Always	Never	4
188	Command timeout	0x0032	100	100	000	Old age	Always	Never	0
189	High fly writes	0x003a	100	100	000	Old age	Always	Never	0
190	Airflow temperature cel	0x0022	078	064	045	Old age	Always	Never	22 (min/max 22/33)
191	G-sense error rate	0x0032	100	100	000	Old age	Always	Never	0
192	Power-off retract count	0x0032	097	097	000	Old age	Always	Never	6763
193	Load cycle count	0x0032	094	094	000	Old age	Always	Never	13915
194	Temperature celsius	0x0022	022	040	000	Old age	Always	Never	22 (0 9 0 0 0)
195	Hardware ECC recovered	0x001a	118	099	000	Old age	Always	Never	168246480
197	Current pending sector	0x0012	100	100	000	Old age	Always	Never	0
198	Offline uncorrectable	0x0010	100	100	000	Old age	Offline	Never	0
199	UDMA CRC error count	0x003e	200	200	000	Old age	Always	Never	0
240	Head flying hours	0x0000	100	253	000	Old age	Offline	Never	1753 (251 22 0)
241	Total lbas written	0x0000	100	253	000	Old age	Offline	Never	50278949009
242	Total lbas read	0x0000	100	253	000	Old age	Offline	Never	157753475851

 

Stop watching it for a couple of hours and see if the speed comes back up. In fact, close the GUI window on your browser!   ("A watch pot never boils" and the GUI takes a lot of CPU cycles...)

Something is definitely not right.  Its slowed down to 5 MB/sec.  Can anyone tell me what will happen if I stop the rebuild and swap disk 8 with the suspect drive?  I could then let it rebuild properly then swap the drives properly (without formatting).

 

Before the starting the array again I will do a full shut down and hopefully fix whatever is slowing everything down at the moment. 

 

I am hoping to get access to the 6.5tb of files I have on the suspect drive while I do all of this.

 

Ok.  I did a cold boot and a new config.  I put the suspect drive back and I am rebuilding parity.  

 

When it is done and I want to replace disk 8 again.  is there any specific requirement?  I already ran preclear on the replacement disk.  do I need to do it again since it was in the array for 24 hours?  

 

Just trying to figure out the safest way to replace disk 8 once parity is back up and running.

 

Edited February 26, 20179 yr by thegizzard

Since you had already lost the ability to rebuild the original "suspect" drive, doing a new parity sync really doesn't hurt anything -- hopefully it will finish much faster than it had been working.    If I'd seen this before you did that, I'd have suggested you wait until it crossed the 5TB point, since at that point the only drives remaining in the rebuild would have been the new 8TB and your parity drive (and your were fairly close to the 5TB point)  -- I'd have expected a BIG jump in speed at that point.   But now you'll never know

 

Assuming the parity sync completes without issue, I'd do two things when it finishes:

(1)  Run a parity check.   This is always a good idea after a new parity sync, just to confirm all went well.

(2)  Then you can rebuild disk 8 to your new disk.   You don't need to do anything with the new disk at that point -- a pre-clear makes no difference when you're doing a rebuild anyway (all it really does in that case is confirm the disk is okay).    It's not strictly necessary, but I'd do this:  (a)  stop the array;  (b) unassign disk 8;  (c) start the array (so disk 8 shows as missing);  (d)  stop the array, then shut down;  (e)  replace the disk with your new one;  (f) boot, assign the new disk as disk 8, then start the array and wait for the rebuild to finish; and finally (g) do a non-correcting parity check to confirm the rebuild completed without error.

 

Thanks Gary. I will do exactly that.

Sent from my SM-N920V using Tapatalk