I have had some problems recently with adding new drives to my array, which I inquired about in this thread. Now that I have upgraded to 4.3beta6, and have a new problem related to adding drives, I thought I would post here.

 

I have the Asus P5B VM-DO board, and was previously trying to add new drives on the jmicron ports. Basically, after every reboot the drives would be identified as new. Today, I tried adding them again, but with the newer 4.3beta6 version.

 

This time I decided to add one drive at a time. The first one was successfully added, and did not appear as new after a reboot. I then decided to add two more drives, one being from my original attempts in the thread linked above, and another a brand new drive I recently purchased. Below are my results

 

disc6: Cleared and formatted, but would not add in 4.2.1. Required to be cleared and formatted before it was successfully added in 4.3beta6 individually.

disc7: Cleared and formatted, but would not add in 4.2.1. Cleared, formatted, added instantaneously when trying to add in 4.3beta6 along with disc8

disc8: Brand new drive. Cleared instantaneously, but reported as unformatted in 4.3beta6.

 

Picture of main page

 

I have also attached the syslog.

 

Should I go ahead and format disc8? How were disc7 and 8 automatically cleared, and disc7 formatted?

You should always get a format button when you have a brand new disk added to the array.

 

If its a brand new disk go ahead and format it.  Somewhere along your disk upgrade lines.  The other 2 drives where formated.  You can use explorer to see if you can view disk 6 & 7 and try and move data to them.

I went ahead and just formatted disc8.

 

My only concern is that disc8 was brand new, and the clearing process was instantaneous. This should not be the case. It took disc6 a few hours to clear, which should be the same for disc8.

well it seems something is really wrong

 

I started a parity check, and now it is reporting nothing but sync errors.

 

I am going to let it complete. I have a feeling it screwed up on disc7 and disc8.

Sync errors aren't unnecessarily a problem.  It just means that you have a disk(s) that is out of sync with the parity drive or the parity drive is out of sync with the disks.  If I recall from another thread your HD's also have self checks in them and could possibly move data around.  Also with new drives I would assume those sync errors are just the new drives being picked up.

 

Once this parity check is complete you can run a second check.  The errors should completely go away or be a very small number.  If you have a lot of errors on the second sync you could have a disk that is starting to fail and others here could look at your syslog file to help you out.

 

As for the clearing I believe in 4.3 Tom rewrote the way drives are formated and cleared that is why it didn't take as long for the format process to finish.

 

 

Sync errors aren't unnecessarily a problem.  It just means that you have a disk(s) that is out of sync with the parity drive or the parity drive is out of sync with the disks.  Also with new drives I would assume those sync errors are just the new drives being picked up.

 

Once this parity check is complete you can run a second check.  The errors should completely go away or be a very small number.  If you have a lot of errors on the second sync you could have a disk that is starting to fail and others here could look at your syslog file to help you out.

 

I agree with most of this.  For some reason the disk clear didn't work on one of your drives.  This is not a trivial issue, and I hope that Tom looks into this.  But given that it happened, you would expect for parity to be a mess - and it is.  You should know that parity errors are corrected by updating the PARITY drive, never by updating a DATA drive.  Therefore, at the end, your parity should be in sync with your data.  No real harm IMO. 

 

If I recall from another thread your HD's also have self checks in them and could possibly move data around. 

 

Irrelevant to this discussion, but want to clarify this.  HDs do, in fact, detect problems and remap marginal sectors using SMART, but they do it in a way that is invisible at the OS level.  You should NEVER get parity errors because SMART remapped a marginal sector.

 

Anecdotal experience - I recently added 2 new 1T drives to my array.  I added them together, they cleared together, and I had zero problems.  This was using 4.3b3 (not b6).

Well parity check finished, but with 7474 errors.

 

I have attached the syslog if anyone is interested.

 

I guess the next thing to do is restart the array, and check the parity again. I will then write some data to the new drives, and test if it copied over correctly.

 

From my experiences so far, it is advisable that you run a parity check after adding new drives to the unRAID array.

I just now got around to checking this thread, and your syslogs, sorry, I was busy.  There's a new problem here, that Brian alluded to.  You are in good shape though, if another parity check is clean.  A parity check after adding drives can't hurt, but is not normally necessary.  But you have had a particularly tough road, trying to upgrade your array.

 

md7: new disk

md8: new disk

emhttp: shcmd (31): killall -w smbd nmbd

emhttp: shcmd (32): /usr/sbin/nmbd -D

emhttp: shcmd (33): /usr/sbin/smbd -D

emhttp: clear_new_disks: open: No such file or directory

emhttp: ... syncing

emhttp: clear_new_disks: fsync: Bad file descriptor

emhttp: writing mbr on disk 8 (/dev/sdd)

 

This extract shows the 2 new drives being added, and then clearing initiated, but failing.  Neither Disk 7 nor Disk 8 were cleared.  There's actually 2 problems here, the first that the clearing failed, and the second is that no error was returned, and unRAID continued on unaware of the clearing failure.

 

In spite of a wrong understanding of the state of the last 2 drives, unRAID completes the process correctly.  After adding the 2 drives and 'clearing' them, it attempts to Start the array, and discovers and mounts a Reiser file system on the first 7 data drives, including Disk 7, which is obviously impossible if it had truly been cleared.  I suspect that Disk 7 was one of the drives that you had previously cleared and formatted over and over, when you had the bad flash that would not save the configuration.  So in this case, that was somewhat fortuitous, in that it was not properly cleared and formatted now when it was supposed to, but had previously been cleared and formatted!  A bit bazaar, to say the least.  Disk 8 was completely empty, so an MBR was written, and a Reiser file system written to it, part of the formatting process.  What is actually very surprising, is that you only had 7474 errors.  Disk 8 must have been almost completely zeroed.  I would have expected millions of parity incorrect errors, and it would have been much faster to have stopped the parity check, and done a parity rebuild.

 

Clearly, this is something Tom should take a look at.

 

Thanks for taking a look Rob.

 

I knew something was wrong when it cleared discs 7 and 8 so fast. Nevertheless, I re-ran the parity check and it returned 0 errors. So I guess it should be good now.

 

Edit: By the way, I am using the same flash as in the previous thread. Tom never replied to my email for a replacement.

In that  case, I sure wouldn't trust that flash.  I would make sure you keep good backups of its contents.  I use SyncBack to sync mine 4 times a day, to a local drive, that is then included in a versioned backup.

Edit: By the way, I am using the same flash as in the previous thread. Tom never replied to my email for a replacement.

Drop Tom another e-mail...include the serial number of a replacement flash drive.  Odds are he responded, but his return message was blocked by a spam filter somewhere.