Nearly everything on the title.

Yesterday I've upsized a hard disk 1TB Seagate to a 2TB Samsung, just after a successful parity check (and cache_dirs disabled).

The new disk is a Samsung HD204UI (japanese firmware 1AQ10003, normally error-free), as the parity disk that I've already installed two months ago.

Of course I've precleared the new disk before.

 

The Upsize process goes without a hitch (Stop, Power Down, Swap disk, Power Up, Start), then I reboot unraid with cache_dirs enabled.

After this I've copied a file (a large one) that goes directly on the new disk (following the write counter on the main page).

 

Now I've start a parity check because I want to upsize another disk, and patatras, 3 sync errors in the beginning.

Jun 13 10:09:47 Tower kernel: md: parity incorrect: 14640 (Errors)

Jun 13 10:09:47 Tower kernel: md: parity incorrect: 14648 (Errors)

Jun 13 10:09:48 Tower kernel: md: parity incorrect: 40016 (Errors)

 

This is something I didn't expect, of course, and now I'm waiting for the end of the parity check to see if there are more errors (9% now).

Parity sync error is something I didn't see before, and I naturally suspect the new disk, even if looking at the smart status nothing look suspect.

 

Now I want to go back and put the previous hard disk back in place, but with the data still on it.

If I put the previous small hard disk back in place, I understand that the parity is invalidated, first because of the errors, then because of the big file I've copied on the new hard disk.

But I think it's a good idea, reconstruct parity, and then swap this disk again but with another new disk.

Now, how to do this, I don't know what will do unraid if I simply swap the disk back (from 2TB to 1TB) ....and for obvious reason I don't want a partial reconstruction.

 

Any idea, advice or what to do next?

syslog-2011-06-13_after_start_of_parity_check_with_errors.txt

Only way to do what you want to do.

 

Stop the array

Power down

Swap in the original drive

Power up

The array will not start, as the disk is the wrong disk AND too small

Login via telnet or on the system console

Type:

initconfig

Respond with

Yes

to its prompt.

 

Refresh the main unRAID page, all the indicators will be blue.  Parity will be invalid.  (as a result of you setting a new disk configuration)

When you next start the array it will completely re-calculate parity.

 

Joe L.

Thanks for your answer.

If I correctly remember, this process looks like the old bad named Restore?

 

I'm still waiting till the end of the parity check process (45% now, still 3 sync errors), just in case there is something to learn.

 

Then I'll follow you.

 

For the next step, I'll make the same Upsize I've made before, but with another new 2TB disk.

 

And now, about the HDD I suspect to be the origin of the sync errors, what should I do to correctly diagnose it? Another preclear? Any clue?

 

 

Your sync errors are in the housekeeping area and not in the data area. I would not recommend going back. I did a rebuild under the new 5.9b7 and had a similar result (4 sync errors). But the data is perfect. There may be a subtle timing but that can cause these sync errors early in the disk. I have reported it to Tom.

Yes, but 3 syncs errors, without any explanation, apart swapping disk, usually leads to suspect something wrong with the new disk.

I've read something astonishing, here, about a nearly similar problem (3 sync errors, on the beginning of the disk in what you call the housekeeping area, with a supermicro sata card) but apparently without a clear resolution.

There are some ideas to follow, like memory test (already done at the birth of this unraid server, but not in between) or complet smart control.

 

Finally I think it's not a good idea to ignore warnings if something can be done.

 

I moved disks around and upgrade-rebuilt one and ended up with 3 parity errors at the very start of the partition of one of my disks. The disk that was used for the rebuild was previously my parity so it wasn't a new disk. None of my drives show any issues and I had no way of testing the file integrety before vs after so I just let it correct the errors and moved on. Now, I'm beginning to believe my errors were caused by some subtle unRAID bug as a number of others have reported havung this similar issue. I'm running on 4.7.

 

Peter

After the different replies here and there about the problem, and here also , I finally left the new drive in the array.

I've managed a lot of parity check, about 10 incomplete (cancelled before 1%, in the housekeeping area) and 3 complete, all successfully.

I really think I can trust my system, I've made a lot of read/write on the new drive without a hitch.

 

 

Now I've just made the same process again for another HDD, upsize from a seagate 1TB to a Samsung 2TB.

So I've already swap one HDD from 1TB to 2TB, this is the second one, on another slot of course.

And again, the same problem arise, but with 7 sync errors.

 

Jun 17 01:13:40 Tower kernel: mdcmd (40): check CORRECT (unRAID engine)

Jun 17 01:13:40 Tower kernel: md: recovery thread woken up ... (unRAID engine)

Jun 17 01:13:40 Tower kernel: md: recovery thread checking parity... (unRAID engine)

Jun 17 01:13:40 Tower kernel: md: using 1152k window, over a total of 1953514552 blocks. (unRAID engine)

Jun 17 01:13:41 Tower kernel: md: parity incorrect: 15312 (Errors)

Jun 17 01:13:41 Tower kernel: md: parity incorrect: 15320 (Errors)

Jun 17 01:13:41 Tower kernel: md: parity incorrect: 16560 (Errors)

Jun 17 01:13:41 Tower kernel: md: parity incorrect: 16568 (Errors)

Jun 17 01:13:41 Tower kernel: md: parity incorrect: 16576 (Errors)

Jun 17 01:13:41 Tower kernel: md: parity incorrect: 17120 (Errors)

Jun 17 01:13:41 Tower kernel: md: parity incorrect: 17128 (Errors)

Those sync errors looks like in the same housekeeping area.

 

3 Possibilities : I'm doing something wrong, my system as a whole is wrong, there is a little bug in the 4.7.

 

The complete process I've made two times :

- Modification of the go file, to REMark the cache_dirs command line.

- Stop the array, Power off.

- Swap a HDD Seagate 1TB to a Samsung 2TB ( HD204UI japanese firmware 1AQ10003, normally error-free).

- Power on the array

- Start the array

- Wait until reconstruction end. Read/Write some file in the array, but not on the disk under construction.

- Re-enable the cache_dirs command line in the go file.

- Stop and Reboot the array.

- Wait till the cache_dirs end reading directories.

- Start the parity check -> sync errors (7 now).

 

The HDDs were connected on a SuperMicro AOC-SASLP-MV8, I've never meet sync errors before, the SATA cables are from SuperMicro also.

The T° are everytime below 48°c, on the reconstruction or the parity check process.

 

Any clue? Little Bug in 4.7?

syslog-2011-06-17_after_start_of_parity_check_with_errors.txt

Bump.

 

I'm going to make the another same upsize a third time shortly.

 

If there's something wrong in the process, can someone spot me what.

 

If not, it's like an unraid 4.7 bug, nothing to care about?

 

Thanks

 

There is an isse. It was fixed in the 5.0b9 I believe.

 

Peter