Hi all,

 

This morning I had a red-balled disk in my array. Stopped the array, powered down, and replaced the drive with a new one of the same size and make. Restarted and, upon assigning the new drive, received the error "Replacement disk is too small." Both the new and old disk are listed as 4TB on the device status page. Figuring there might be a problem with the new drive, I tried another new drive with the same results. unRAID Server Pro version: 5.0.4. System log attached. Any help would be greatly appreciated.

 

Thanks!

systemLog.txt

You likely have an HPA on the new disks. Are you running a gigabyte motherboard?

Thanks for the reply. I saw this potential cause mentioned in other posts involving the "replacement disk too small" error, however I don't believe this is my problem there's no indication HPA was detected in my log and my motherboard is a SuperMicro.

Did you try to run the hdparm -N command on the drive?

Thank you for the suggestion. Running hdparm -N gets this result: "READ_NATIVE_MAX_ADDRESS_EXT failed: Input/output error." I was able to run hdparm -I and hdparm -tT successfully on the same drive. Not sure what to make of this.

 

root@Tower:~# hdparm -I /dev/sdd

 

/dev/sdd:

 

ATA device, with non-removable media

Model Number:      WDC WD40EZRX-00SPEB0                   

Serial Number:      WD-WCC4E0614977

Firmware Revision:  80.00A80

Transport:          Serial, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0

Standards:

Supported: 9 8 7 6 5

Likely used: 9

Configuration:

Logical max current

cylinders 16383 16383

heads 16 16

sectors/track 63 63

--

CHS current addressable sectors:  16514064

LBA    user addressable sectors:  268435455

LBA48  user addressable sectors: 7813971633

Logical  Sector size:                  512 bytes

Physical Sector size:                  4096 bytes

device size with M = 1024*1024:    3815415 MBytes

device size with M = 1000*1000:    4000753 MBytes (4000 GB)

cache/buffer size  = unknown

Nominal Media Rotation Rate: 5400

Capabilities:

LBA, IORDY(can be disabled)

Queue depth: 32

Standby timer values: spec'd by Standard, with device specific minimum

R/W multiple sector transfer: Max = 16 Current = 16

DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6

    Cycle time: min=120ns recommended=120ns

PIO: pio0 pio1 pio2 pio3 pio4

    Cycle time: no flow control=120ns  IORDY flow control=120ns

Commands/features:

Enabled Supported:

  * SMART feature set

    Security Mode feature set

  * Power Management feature set

  * Write cache

  * Look-ahead

  * WRITE_BUFFER command

  * READ_BUFFER command

  * NOP cmd

  * DOWNLOAD_MICROCODE

    Power-Up In Standby feature set

  * SET_FEATURES required to spinup after power up

  * 48-bit Address feature set

  * Device Configuration Overlay feature set

  * Mandatory FLUSH_CACHE

  * FLUSH_CACHE_EXT

  * SMART error logging

  * SMART self-test

  * General Purpose Logging feature set

  * 64-bit World wide name

  * WRITE_UNCORRECTABLE_EXT command

  * {READ,WRITE}_DMA_EXT_GPL commands

  * Segmented DOWNLOAD_MICROCODE

  * Gen1 signaling speed (1.5Gb/s)

  * Gen2 signaling speed (3.0Gb/s)

  * Gen3 signaling speed (6.0Gb/s)

  * Native Command Queueing (NCQ)

  * Host-initiated interface power management

  * Phy event counters

  * NCQ priority information

  * unknown 76[15]

    DMA Setup Auto-Activate optimization

    Device-initiated interface power management

  * Software settings preservation

  * SMART Command Transport (SCT) feature set

  * SCT Write Same (AC2)

  * SCT Features Control (AC4)

  * SCT Data Tables (AC5)

    unknown 206[12] (vendor specific)

    unknown 206[13] (vendor specific)

    unknown 206[14] (vendor specific)

  * reserved 69[4]

Security:

Master password revision code = 65534

supported

not enabled

not locked

frozen

not expired: security count

supported: enhanced erase

more than 508min for SECURITY ERASE UNIT. 2min for ENHANCED SECURITY ERASE UNIT.

Logical Unit WWN Device Identifier: 50014ee2b4351d95

NAA : 5

IEEE OUI : 0014ee

Unique ID : 2b4351d95

Checksum: correct

root@Tower:~# hdparm -tT /dev/sdd

 

/dev/sdd:

Timing cached reads:  2278 MB in  2.00 seconds = 1139.78 MB/sec

Timing buffered disk reads: 426 MB in  3.01 seconds = 141.53 MB/sec

 

 

 

Some controllers don't support "-N". If you are able to easily move one of the drives to a motherboard SATA port that would allow you to run it and, if it has an HPA, to remove it.

 

Besides a gigabyte MB, the other way I am aware of HPAs appearing on disks is if you pull it from an external drive enclosure. The HPA is not a problem most of the time, but for parity and rebuilding having a disk even a tiny bit smaller is a problem.

 

I think there are other ways to delete an HPA but this is the one I know.

Thank you again for your help. I don't think it's the controller. I was able to run hdparm -N on all of the other drives in the array without error. Also, this drive, as well as the previous drive I received the "drive too small" error on, were both new out of the box. Any other thoughts or suggestions would be greatly appreciated.

Thank you again for your help. I don't think it's the controller. I was able to run hdparm -N on all of the other drives in the array without error. Also, this drive, as well as the previous drive I received the "drive too small" error on, were both new out of the box. Any other thoughts or suggestions would be greatly appreciated.

At this point, It would be really helpful if you could set up a temporary test rig, and boot a free version of unraid on another box entirely with only the drive in question and the usb stick connected. Save and post that syslog, so we can compare the reported size of the drive. There is a definite reported size difference where there shouldn't be, and in order to troubleshoot that we need to change how things are connected and try again. If the error follows the drive to a different box, then it's got to be a problem with the drive. Conversely, if the drive reports the correct size when connected elsewhere, it's got to be the controller or port in your server.

Hi Johnathan. I did't have a spare system to use as a testbed, so I swapped the drive in question into the cache drive slot and vice versa. In this configuration, I was able to run hdparm -N on the cache drive (now in the bad drive slot), but received the same error on the questionable drive (now in the cache drive slot). That indicated it was the drive. Got a new Seagate drive and that's rebuilding fine now. My concern is that 2 brand new WD 4TB drives failed in a row - not returning HPA data when queried. Is that just bad luck, or could there be REVs of WD drives incompatible with Unraid?

 

Again, thanks for the help.

 

 

I've had similar issues where hdparm didn't produce proper results either, though the drives were fine.

 

Out of curiosity, did you take these drives from an external enclosure, or were they purchased as internal drives? I had 3 drives with similar issues, but they were all external drives I cracked out of the cases. Even though hdparm and other other tools did not show a HPA they did have slightly smaller sizes than stand alone internal disks. I never did figure out why, but since I wasn't looking at using any of them for parity I didn't pursue it too deeply.

 

Both drives that produced the error were new WD internal drives installed in the Unraid array straight out of the box.

Very odd. I will request some details from the WDs tomorrow to see if we can better understand the size difference.