I bought 4 WD 5TB Elements external drives in April, 2015 when it was reported that they contained red drives inside.  I received 3 reds and 1 green drive.  Unraid shows that each of these drives has a capacity of 5,000,981,078,016 bytes.

 

In December 2015, I bought 3 more WD 5TB Elements [correction: these were MyBook external drives, not Elements] external drives and got 3 green drives. Unraid shows each of these three greens has a capacity of 5,000,947,524,096 bytes which is 33,553,920 bytes smaller than the drives I received in April. 

 

33 MB is not a lot of space.  However, the slightly smaller size has an impact on how they can be used in Unraid. Here's what I've learned.

 

On my last parity check, Unraid reported 122 read errors on my parity drive, which is one of the older red drives. Because the new green drive is slightly smaller than the old red drive, unraid would not permit the new green drive to replace the older parity drive because the parity drive has to be at least as big as any other drive in the array.

 

I gather this also means that if any of the slightly larger drives failed, the new green drive would not be able to used to replace them.

 

The new green drive is also not going to work as a 2nd parity drive, when that feature becomes available.

 

I'd like to know if anyone else is using a 5TB drive pulled from a WD Elements external drive in their unraid server. If so, could you go to the "identity" section of unraid's disk

informaton and post the number reported as "User Capacity".

 

Another thing that might be the problem is that there are two partitions on those new drives.  (Sometimes, Drive manufacturers add a second partition so that they can permanently store software on the small one.)

I got the data on drive sizes as follows. Start on Unraid's Main page, click on any of the drives -> Parity, Disk1, Disk2, etc.  This will bring you to a screen full of information about the drive.  If you scroll down to section labeled "Identity" there will be a line labeled "User capacity:" I believe that number is being reported by the drive and includes all partitions. 

 

In the images below, the first one is for a WD Green 5TB drive pulled from a WD Elements case purchased in December 2015.  The second image is for another WD Green 5TB drive pulled from a WD Elements case in April 2015.

 

I'm curious to know if anyone else is seeing the same size difference between old and new 5TB drives?

I'm going to guess this only affects external drives...  still a nasty trick however.

You should check for HPA on the smaller disks:

 

hdparm -N /dev/sdX

 

X=drive letter

Both of these drives were pulled from external enclosures. The only difference is one was purchased in April and one in December of 2015.

If you scroll down to section labeled "Identity" there will be a line labeled "User capacity:" I believe that number is being reported by the drive and includes all partitions. 

 

Does anyone know for sure that it's doing that? Because I could totally see that line as only space the on the drive that the user can use... which if there is a protected partition would be less then the full drive.

@johnnie.black

 

Here is the response I get:

 

root@Media:~# hdparm -N /dev/sdf

/dev/sdf:
READ_NATIVE_MAX_ADDRESS_EXT failed: Input/output error
root@Media:~#

 

I get the same response for each drive.

 

What would a normal response be?

@gundamguy

 

I would like to know if my assumption about the drive size is correct as well.

What would a normal response be?

 

 

root@Tower5:~# hdparm -N /dev/sde

/dev/sde:
max sectors   = 11721045168/11721045168, HPA is disabled

 

Maybe try different controller...

 

 

@johnnie.black

 

Thanks for posting what a normal response for hdparm should be.  What do you make of the response I got?

If you can try a different controller, some HBAs don’t respond to that command.

@ johnnie.black

 

Are there any other commands I could use to get this information without having to change out the HBA?

It’s not always reported, but you can search your syslog for HPA, if reported it will appear similar to this:

 

Jan 14 01:49:38 Tower kernel: ata5.00: HPA detected: current 65134, native 1953525168
Jan 14 01:49:38 Tower kernel: ata5.00: ATA-8: Hitachi HDT721010SLA360, ST6OA31B, max UDMA/133

 

@johnnie.black

 

I looked through my syslogs and did not find anything regarding an HPA.  I've attached my syslog file in case you might be able to see something I missed.  Thanks for your help and suggestions.

 

media-syslog-20160115-0942.zip

I just checked a WD Blue drive that I remove from and external drive and it's the smaller size. I ran the program Active Kill Disk to make sure there were no partitions with no change. The size shown in the Identity tab come from the drive itself and is fixed by WD. This is bad as these drives cannot be used to replace another 5TB that is the normal size and should not be used as a parity drive unless all drives are the same.

Don’t see nothing that confirms HPA, but that is still my best guess.

 

Also, there are many errors on your cache SSD device, like these:

 

Jan 14 06:45:10 Media kernel: ata5.00: failed command: READ FPDMA QUEUED
Jan 14 06:45:10 Media kernel: ata5.00: cmd 60/20:d8:60:5f:1c/00:00:00:00:00/40 tag 27 ncq 16384 in
Jan 14 06:45:10 Media kernel:         res 40/00:01:01:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
Jan 14 06:45:10 Media kernel: ata5.00: status: { DRDY }
Jan 14 06:45:10 Media kernel: ata5.00: failed command: READ FPDMA QUEUED
Jan 14 06:45:10 Media kernel: ata5.00: cmd 60/08:e0:20:8b:45/00:00:2b:00:00/40 tag 28 ncq 4096 in
Jan 14 06:45:10 Media kernel:         res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
Jan 14 06:45:10 Media kernel: ata5.00: status: { DRDY }
Jan 14 06:45:10 Media kernel: ata5.00: failed command: READ FPDMA QUEUED
Jan 14 06:45:10 Media kernel: ata5.00: cmd 60/08:e8:c0:fc:21/00:00:24:00:00/40 tag 29 ncq 4096 in
Jan 14 06:45:10 Media kernel:         res 40/00:01:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
Jan 14 06:45:10 Media kernel: ata5.00: status: { DRDY }
Jan 14 06:45:10 Media kernel: ata5.00: failed command: READ FPDMA QUEUED
Jan 14 06:45:10 Media kernel: ata5.00: cmd 60/08:f0:80:a3:69/00:00:2a:00:00/40 tag 30 ncq 4096 in
Jan 14 06:45:10 Media kernel:         res 40/00:01:01:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
Jan 14 06:45:10 Media kernel: ata5.00: status: { DRDY }
Jan 14 06:45:10 Media kernel: ata5: hard resetting link

@johnnie.black

 

Thanks for taking a look at my syslog.  I did not realize my cache drive was throwing errors.  I will change the SATA cable to that drive and pay more attention to the log file.

 

Given Wally's response, the one right before your last post, do you still think this is an HPA issue?  Wally used Active Kill Disk to verify that there was no HPA on his recently purchased WD Blue 5TB drive. He says his drive is the same size as my smaller Green drive.

Didn't see that post, if that util detects hpa and it wasn't present then yours are probably the same.

It turns out the 4 drives purchased in April were pulled from a WD Elements external drive.  However, the 3 purchased in December were pulled from a WD MyBook external drive. It may be that the drives inside WD's Elements are the normal size, and its only the drives that are inside a MyBook that are slightly smaller.

 

In any case, the smaller 5TB drives are fine for data, but should not be used as a parity drive, and unraid won't be able to use them to rebuild any other brand of 5TB drive.

 

Just thought I would add some more data. Just bought (Jan 2016) a WD 5TB My Book and it is reporting the smaller size of 5,000,947,524,096. Does seem to make it look the the "My Book" externals are slightly smaller. Granted this is my only 5TB drive and chances are by the time I need to upgrade the next drive will be 6 or 8 TB so I do not think I will run into any issues. It is a good to keep in mind though.