[Solved] Samsumg 2tb 203WI showing funny size and connection

[tr0910]

• I have a 203wi that spend the first year of its life in a Buffalo LS-Live Linkstation.  This unit has outlived its usefulness and the drive was precleared and added to an unraid box.  The drive appears to be working fine, however, 2 funny things happened.  First, the drive is showing up with 1,953,513,492 instead of 1,953,514,552 total capacity.  Secondly, it shows up differently attached as hdd rather than sdb:

 

disk1 device:	pci-0000:00:11.0-scsi-2:0:0:0 host3 (sdb) SAMSUNG_HD203WI_S1UYJ1WZ405310
disk2 device:	pci-0000:00:14.1-ide-1:1 ide1 (hdd) SAMSUNG_HD203WI_S1UYJ1CZ415039
disk3 device:	pci-0000:00:11.0-scsi-1:0:0:0 host2 (sda) SAMSUNG_HD204UI_S2H7J1AZC09470[/list]

I tried to run hdparm -N /dev/[hs]d[a-z] on it to see if there might be an HPA on it somewhere, but hdparm doesn't like that drive.

 

The running kernel lacks CONFIG_IDE_TASK_IOCTL support for this device.
READ_NATIVE_MAX_ADDRESS_EXT failed: Invalid argument

I tried this command on my other identical unraid box and it ran as expected.  Should I worry about this drive and the funny way it is attached?  Motherboard is Asus m4a 785 m running unraid 4.7

 

puzzled

 

 

[Joe L.]

I have a 203wi that spend the first year of its life in a Buffalo LS-Live Linkstation.  This unit has outlived its usefulness and the drive was precleared and added to an unraid box.  The drive appears to be working fine, however, 2 funny things happened.  First, the drive is showing up with 1,953,513,492 instead of 1,953,514,552 total capacity.  Secondly, it shows up differently attached as hdd rather than sdb:

 

disk1 device:	pci-0000:00:11.0-scsi-2:0:0:0 host3 (sdb) SAMSUNG_HD203WI_S1UYJ1WZ405310
disk2 device:	pci-0000:00:14.1-ide-1:1 ide1 (hdd) SAMSUNG_HD203WI_S1UYJ1CZ415039
disk3 device:	pci-0000:00:11.0-scsi-1:0:0:0 host2 (sda) SAMSUNG_HD204UI_S2H7J1AZC09470[/list]

I tried to run hdparm -N /dev/[hs]d[a-z] on it to see if there might be an HPA on it somewhere, but hdparm doesn't like that drive.

 

The running kernel lacks CONFIG_IDE_TASK_IOCTL support for this device.
READ_NATIVE_MAX_ADDRESS_EXT failed: Invalid argument

I tried this command on my other identical unraid box and it ran as expected.  Should I worry about this drive and the funny way it is attached?  Motherboard is Asus m4a 785 m running unraid 4.7

 

puzzled

 

 

It probably does have an HPA.  The proper size should end in 552.

 

You've got the disk controller it is attached to set to a "legacy" IDE emulation mode, that is why it is showing as an hd? device instead of an sd? device..  (This is a BIOS setting on your motherboard)  It should be set to AHCI mode.  You can change it and unRAID will still recognize the drive, although it will probably be a bit faster, since the legacy IDE emulation modes are typically much slower.

 

 

[tr0910]

Thanks Joe, it help from you and the other awesome people here that make unraid such a valuable tool.  I am attempting to take unraid into a mission critical use, and want to test it to death first.  

 

I redid the bios, readded disk2 and everything seems fine again.  Here is what hdparm found though.   No HPA?

 

/dev/sda:
max sectors   = 3907029168/14715056(18446744073321613488?), HPA setting seems invalid (buggy kernel device driver?)

/dev/sdb:
max sectors   = 3907029168/14715056(18446744073321613488?), HPA setting seems invalid (buggy kernel device driver?)

/dev/sdc:
max sectors   = 3907027055/14715056(18446744073321613488?), HPA setting seems invalid (buggy kernel device driver?)

/dev/sdd:
HDIO_DRIVE_CMD(identify) failed: Invalid exchange

 

 

[tr0910]

Thanks Joe, it help from you and the other awesome people here that make unraid such a valuable tool.  I am attempting to take unraid into a mission critical use, and want to test it to death first.  

 

I redid the bios, readded disk2 and everything seems fine again.  Here is what hdparm found though.   No HPA?

 

/dev/sdc:
max sectors   = 3907027055/14715056(18446744073321613488?), HPA setting seems invalid (buggy kernel device driver?)

 

Still concerned about the HPA issue, and not being satisfied to just let the drive continue running quietly, and not causing me any problems I dug deeper into the knowledge base here.  Based on my syslog entry of:

 

Mar 22 12:07:41 Tower2 kernel: ata6.00: HPA detected: current 3907027055, native 3907029168

 

I entered the

 

hdparm -N p3907029168 /dev/sde 

 

and after shutting down the array and rebooting, the server, that disk came back up with the full size of 1,953,514,552 and the disk went blue, and restarting the rebuild process has the array rebuilding disk2 from parity as we speak.  10 hours to go........

[tr0910]

and after shutting down the array and rebooting, the server, that disk came back up with the full size of 1,953,514,552 and the disk went blue, and restarting the rebuild process has the array rebuilding disk2 from parity as we speak.  10 hours to go........

 

Disk has now completely rebuilt and is green balled and is showing the right size.  Hdparm worked fine.

 

Now I am still confused as to why the HPA was installed because this disk was never on a Gigabyte mb to my knowledge.  Can a Linkstation Pro install a HPA?

[tr0910]

Now I know why this drive had an HPA...  It was hooked up to a Gigabyte motherboard for only a few minutes to adjust the partition size with Gparted when this disk was installed into a Linkstation Pro.

 

In these few minutes, the dirty work was done.