Migration problem...building new array, "drive in parity slot not biggest"

I just finished migrating all my data disk by disk from my old array, which was a setup of 6 2TB drives.  I'm now using 4 6TB drives.  I first created a 3-disk array with no parity and copied all data over from my old disks one-by-one, using PuTTy and the cp command from a terminal.  (Disks 1 and 2 were copied to new disk 1, 3 and 4 to new disk 2, 5 to new disk 3, etc.)

Then I stopped the array and tried to assign the last 6TB drive as parity.

I keep getting a "drive in parity slot not biggest" message in the unRAID interface and it won't let me start the array.  Help?

All disks are WD 6 TB Reds using the XFS file system.  I am on a consumer ASRock motherboard.

check for HPA

hdparm -N /dev/sdX

And please see Need help? Read me first!, and attach the diagnostics zip.

check for HPA

 

hdparm -N /dev/sdX

On the drive I'm trying to use as my parity, and on the first assigned disk:  READ_NATIVE_MAX_ADDRESS_EXT failed:  Input/Output error

On disks 2 and 3:  HPA disabled

Adding diagnostic info to post.

dg_fileserver-diagnostics-20160327-1645.zip

Where any of those disks from external enclosures?

Two are smaller than the other two

Mar 27 16:43:59 DG_FileServer kernel: ata3.00: ATA-9: WDC WD60EFRX-68L0BN1,      WD-WX21DA5FN9ZR, 82.00A82, max UDMA/133

Mar 27 16:43:59 DG_FileServer kernel: ata3.00: 11721045168 sectors, multi 16: LBA48 NCQ (depth 31/32), AA

 

Mar 27 16:43:59 DG_FileServer kernel: ata4.00: ATA-9: WDC WD60EFRX-68MYMN1,      WD-WX21D65NV1TZ, 82.00A82, max UDMA/133

Mar 27 16:43:59 DG_FileServer kernel: ata4.00: 11720979633 sectors, multi 16: LBA48 NCQ (depth 31/32), AA

 

Mar 27 16:43:59 DG_FileServer kernel: ata6.00: ATA-9: WDC WD60EFRX-68L0BN1,      WD-WXB1HB4SFY25, 82.00A82, max UDMA/133

Mar 27 16:43:59 DG_FileServer kernel: ata6.00: 11721045168 sectors, multi 16: LBA48 NCQ (depth 31/32), AA

 

Mar 27 16:43:59 DG_FileServer kernel: ata8.00: ATA-9: WDC WD60EFRX-68MYMN1,      WD-WX21D65NV4TC, 82.00A82, max UDMA/133

Mar 27 16:43:59 DG_FileServer kernel: ata8.00: 11720979633 sectors, multi 16: LBA48 NCQ (depth 31/32), AA

No, I purchased all 4 drives as bare OEM drives.  2 from Amazon, 2 from Newegg.  All drives passed their preclears with no issues.

Doesn't look like HPA is enable, unless someone has a better solution you have to use one of the largest (-68L0BN1) as the parity disk.

So are you saying that there are different types of WD Red 6TB drives out there, and one happens to be ever so slightly smaller?

WTF Western Digital?

First time I've seen it with internal disks, it happened to other users with externals.

What's the best procedure for getting unRAID to drop one of the other disks from the array?  Do I use the "New Config" tool and re-arrange the last disk with the disk I was trying to use as parity?

You can if it's empty.

The (intended) parity drive is empty, the other disks are not.  I just finished transferring all of my data over to them.  Is it possible to copy disk3's contents over to the empty drive and then swap the empty drive and disk3?

Do a new config and assign all disks as data disks, leave parity slot empty, move/copy data then do another new config.

I have the unassigned devices plugin, so I have access to unassigned disks.  I'm copying disk3 over now, then I'll do a new config and set it to a parity drive.

Update:

I completed the transfer from my previous disk 3 over to the drive I intended to be the parity, then did a New Config.  I confirmed that unRAID will accept my newly assigned parity drive.  But unRAID also decided that the new disk 3, despite having been formatted XFS prior to the file transfer, was "unrecognizable" and forced me to do a format.  I have once again disabled my parity and began another transfer of my last disk5 from my old array onto the new disk 3, after which I will re-add parity and cache to the array and let it do its parity sync.

Apparently one tip that I was given on Reddit is that, the next time I'm building an array, I should shave off about a GB or so off of the partition size for each disk, so that if I run into a slight mismatch like this, I have some breathing room.  By my estimate, I believe the difference in disk size was about 250 MB or so.

You shouldn't have to do that though, this is an unwelcome and uncommon surprise.  I'm thinking it might be good to put out a warning on one of the hardware boards here, to avoid the WD60EFRX-68MYMN1 model for parity drives.  It looks to be only 32MB short, but even one sector invalidates its use for a parity drive, unless you buy all the same or smaller drives.

It would be helpful if you could determine which drives you bought at Newegg and which you bought at Amazon, in case only one of them is providing the smaller one.

I don't really have any way of knowing, unfortunately.  Both of my invoices just say "WD60EFRX" but don't break down the model any further than that.

Anecdotal, but one Redditor said that, out of an order of eight 6TB Reds, 5 or 6 were the slightly larger model and then the rest were 68MYMN1 models.

Also...is it possible/realistic to see parity sync speeds of 165-170 MB/sec?  Should I be worried?  I know I'd be worried if it were going too slow, but I thought 30-50MB/sec was more normal.

Also...is it possible/realistic to see parity sync speeds of 165-170 MB/sec?  Should I be worried?  I know I'd be worried if it were going too slow, but I thought 30-50MB/sec was more normal.

That's normal for the beginning of those disks, it will slow down gradually and end up <80MB/s, average should be ~110MB/s.

30-50MB/s is usually the normal write speed to a protected array.

... By my estimate, I believe the difference in disk size was about 250 MB or so.

Actually the difference in the sizes was 32MB  (33,553,920 bytes to be precise).

First case I've seen where the same WD model # had different sizes, however.

Yeah, I figured that out.  I was basing my estimate off the physical sector size, not the logical sector size.

Found the problem ... did a warranty check on WD's site to see if there was an obvious difference in the dates of these drives -- and discovered something very interesting ...

The two larger drives (clearly the correct size for 6TB WD Reds) show as "WD Red" drives

The two smaller drives show as "My Book for Mac" units.    Clearly these were removed from an external enclosure.  If you didn't do this, then I'd guess you bought these from a seller who was harvesting drives from an external enclosure and selling them as OEM.    Note that both Newegg and Amazon act as agents for 3rd party resellers [both sites will show when this is the case -- if it shows "Ships from and sold by Amazon.com", or "Sold and shipped by Newegg", then it's safe, but if it's from another reseller you could encounter this kind of issue.]

Here's the actual result of the WD Warranty check for your drives ...

You shouldn't have to do that though, this is an unwelcome and uncommon surprise.  I'm thinking it might be good to put out a warning on one of the hardware boards here, to avoid the WD60EFRX-68MYMN1 model for parity drives.

Fortunately this isn't an issue => as you can see from the posts I just made the WD Reds are fine ... the drives that are a bit smaller were harvested from an external enclosure => which is already known to be an issue in many cases.    The real question here is who was selling harvested drives as new OEM drives !!    I doubt it was either Amazon or Newegg ... it was almost certainly one of their 3rd party sellers, since daggah said he bought all of them as OEM drives.

That's a good catch, garycase.  I wonder if there are other concerns I should have now based on this.  The "My Book for Mac" harvested drives passed their preclears just fine and I now have my array built after swapping drives; just waiting on the parity check.  I'm not really sure if I should take any action at this stage, other than the concern that this will possibly screw me if I need warranty coverage.