Strange HD. What is this thing?

Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.

Fritz

Well-Known Member
Apr 6, 2015
3,372
1,375
113
69
Bought this drive on eBay. Seller says it's a "Clipped" Label says it's a 4TB HUS726040ALS210.

It identifies itself as a 3TB HUS72604CLAR3000.

Seller says drive was a replacement that was clipped by the manufacturer to 3TB because it replaced a 3TB that they didn't have in stock.

The drive has absolutely not been tampered with. As you can see in the pic, the placement of the label is too perfect to have been done by hand (I think).

I put it in an SAS3 server and it auto negotiated to 12G. (Would a 6G drive do this in a 12G system?)

The seller says the clipping might be removable and thus restoring the drive to full capacity.

The seller was perfectly honest. The drive was sold as a 3TB at a good price and lifetime writes are a little over 8TB so I'm satisfied with the drive. Just curious as hell.

P1030854sm.jpg
 

Fritz

Well-Known Member
Apr 6, 2015
3,372
1,375
113
69

Markess

Well-Known Member
May 19, 2018
1,146
761
113
Northern California
That's interesting. Its like they've binned the same model drive into two capacities, like they used to do (still do?) with CPUs so they'd have SKUs at different price points.

Did you see this post (below)? The OP in that post says there were also HUS726040ALS210 in 4TB capacity with model number HUS72604CLAR4000 (vs 3000 for the 3TB model). That person had no luck with trying to flash the stock Hitachi firmware, but I wonder if you could bring the capacity back to 4TB with the HUS72604CLAR4000 firmware? Although I've got no clue how to get that from Dell/EMC to even try it.

View topic - HGST HUS726040ALS210 from EMC clarion formated to 3TB
 
  • Like
Reactions: Fritz

Fritz

Well-Known Member
Apr 6, 2015
3,372
1,375
113
69
That's interesting. Its like they've binned the same model drive into two capacities, like they used to do (still do?) with CPUs so they'd have SKUs at different price points.

Did you see this post (below)? The OP in that post says there were also HUS726040ALS210 in 4TB capacity with model number HUS72604CLAR4000 (vs 3000 for the 3TB model). That person had no luck with trying to flash the stock Hitachi firmware, but I wonder if you could bring the capacity back to 4TB with the HUS72604CLAR4000 firmware? Although I've got no clue how to get that from Dell/EMC to even try it.

View topic - HGST HUS726040ALS210 from EMC clarion formated to 3TB
Yea, probably a waste of time to even try. If it was possible I'm sure the answer would be out there and apparently it's not. :(
 

amp88

Member
Jul 9, 2020
59
63
18
Bit of a long shot, but did anyone find a way to format and/or flash these drives to unlock the full 4TB capacity?
 

Fritz

Well-Known Member
Apr 6, 2015
3,372
1,375
113
69
I found a program that supposedly restores a clipped drive to full capacity but it didn't work. I emailed the author and he replied that at present it works for SATA drives only, not SAS drives.

This drive continues to function normally as a 3TB drive.

EDIT: Program is HDAT2.
 
  • Like
Reactions: amp88

amp88

Member
Jul 9, 2020
59
63
18
I found a program that supposedly restores a clipped drive to full capacity but it didn't work. I emailed the author and he replied that at present it works for SATA drives only, not SAS drives.

This drive continues to function normally as a 3TB drive.
Ah, that's a shame. Thanks for the quick reply though.

I just got another EMC KTN-STL3 with fifteen of these in it and thought I'd won a small victory in the eBay lottery when I checked the drive labels. Then, of course, I realised they were limited to 'only' 3TB in firmware when I was checking them out.

Well, I bought them as 3TB, so I didn't lose out. Just reformatting them to 512 byte sectors at the moment.
 

ServerPartDeals

New Member
Nov 29, 2022
4
13
3
Try the following from a linux environment to see if it can be 'unclipped'

sg_scan -i
(to identify the drives)

sg_format --format --count=-1 --size=512 /dev/XXX
(replace XXX)

or

sg_format --resize --count=-1 /dev/XXX
(replace XXX)
 
  • Like
Reactions: amp88 and Fritz

Fritz

Well-Known Member
Apr 6, 2015
3,372
1,375
113
69
Try the following from a linux environment to see if it can be 'unclipped'

sg_scan -i
(to identify the drives)

sg_format --format --count=-1 --size=512 /dev/XXX
(replace XXX)

or

sg_format --resize --count=-1 /dev/XXX
(replace XXX)
Thanks. Noted for the future. I've already scrapped the drive. After countless failed attempts I decided I valued my sanity more than the drive.
 

amp88

Member
Jul 9, 2020
59
63
18
Try the following from a linux environment to see if it can be 'unclipped'

sg_scan -i
(to identify the drives)

sg_format --format --count=-1 --size=512 /dev/XXX
(replace XXX)

or

sg_format --resize --count=-1 /dev/XXX
(replace XXX)
Interesting, thanks. I might give the resize command a try in the next few days. I don't have the drives powered on at the moment to test with.

I'm just going through the sg_format source code to try to determine what it queries on the drive to get the "maximum block count"/"maximum number of blocks" when you give the parameter -1 to count. My assumption would be that it uses the value supplied by the EMC firmware, which would leave the capacity unchanged, at 3TB. The manpage also says that if you attempt to manually pass a value higher then the command will fail with the drive reporting an error, but I'll give it a go anyway just to see what happens.
 
  • Like
Reactions: Fritz

amp88

Member
Jul 9, 2020
59
63
18
OK, I just gave it a go, but no luck. Thanks for the suggestion though.

Code:
ubuntu@ubuntu:~$ sudo sg_readcap /dev/sg1
READ CAPACITY (10) indicates device capacity too large
  now trying 16 byte cdb variant
Read Capacity results:
   Protection: prot_en=0, p_type=0, p_i_exponent=0
   Logical block provisioning: lbpme=0, lbprz=0
   Last LBA=5860533167 (0x15d50a3af), Number of logical blocks=5860533168
   Logical block length=512 bytes
   Logical blocks per physical block exponent=0
   Lowest aligned LBA=0
Hence:
   Device size: 3000592982016 bytes, 2861588.5 MiB, 3000.59 GB, 3.00 TB
  
  
ubuntu@ubuntu:~$ sudo sg_format --resize --count=-1 /dev/sg1
    HITACHI   HUS72604CLAR3000  N9C0   peripheral_type: disk [0x0]
      << supports protection information>>
      Unit serial number: K4H6SXBB
      LU name: 5000cca25d44ae04
Mode Sense (block descriptor) data, prior to changes:
  <<< longlba flag set (64 bit lba) >>>
  Number of blocks=5860533168 [0x15d50a3b0]
  Block size=512 [0x200]
Resize operation seems to have been successful


ubuntu@ubuntu:~$ sudo sg_readcap /dev/sg1
READ CAPACITY (10) indicates device capacity too large
  now trying 16 byte cdb variant
Read Capacity results:
   Protection: prot_en=0, p_type=0, p_i_exponent=0
   Logical block provisioning: lbpme=0, lbprz=0
   Last LBA=5860533167 (0x15d50a3af), Number of logical blocks=5860533168
   Logical block length=512 bytes
   Logical blocks per physical block exponent=0
   Lowest aligned LBA=0
Hence:
   Device size: 3000592982016 bytes, 2861588.5 MiB, 3000.59 GB, 3.00 TB
  
  
ubuntu@ubuntu:~$ sudo sg_format --resize --count=7814044224 /dev/sg1
    HITACHI   HUS72604CLAR3000  N9C0   peripheral_type: disk [0x0]
      << supports protection information>>
      Unit serial number: K4H6SXBB
      LU name: 5000cca25d44ae04
Mode Sense (block descriptor) data, prior to changes:
  <<< longlba flag set (64 bit lba) >>>
  Number of blocks=5860533168 [0x15d50a3b0]
  Block size=512 [0x200]
Try MODE SELECT again with SP=0 this time
MODE SELECT command: Illegal request
    try '-v' for more information
sg_format failed: Illegal request
ubuntu@ubuntu:~$ sudo sg_format --resize --count=5860533169 /dev/sg1
    HITACHI   HUS72604CLAR3000  N9C0   peripheral_type: disk [0x0]
      << supports protection information>>
      Unit serial number: K4H6SXBB
      LU name: 5000cca25d44ae04
Mode Sense (block descriptor) data, prior to changes:
  <<< longlba flag set (64 bit lba) >>>
  Number of blocks=5860533168 [0x15d50a3b0]
  Block size=512 [0x200]
Try MODE SELECT again with SP=0 this time
MODE SELECT command: Illegal request
    try '-v' for more information
sg_format failed: Illegal request
ubuntu@ubuntu:~$
 

amp88

Member
Jul 9, 2020
59
63
18

mrpburke

New Member
Sep 29, 2023
6
0
1
OK, I just gave it a go, but no luck. Thanks for the suggestion though.

Code:
ubuntu@ubuntu:~$ sudo sg_readcap /dev/sg1
READ CAPACITY (10) indicates device capacity too large
  now trying 16 byte cdb variant
Read Capacity results:
   Protection: prot_en=0, p_type=0, p_i_exponent=0
   Logical block provisioning: lbpme=0, lbprz=0
   Last LBA=5860533167 (0x15d50a3af), Number of logical blocks=5860533168
   Logical block length=512 bytes
   Logical blocks per physical block exponent=0
   Lowest aligned LBA=0
Hence:
   Device size: 3000592982016 bytes, 2861588.5 MiB, 3000.59 GB, 3.00 TB
 
 
ubuntu@ubuntu:~$ sudo sg_format --resize --count=-1 /dev/sg1
    HITACHI   HUS72604CLAR3000  N9C0   peripheral_type: disk [0x0]
      << supports protection information>>
      Unit serial number: K4H6SXBB
      LU name: 5000cca25d44ae04
Mode Sense (block descriptor) data, prior to changes:
  <<< longlba flag set (64 bit lba) >>>
  Number of blocks=5860533168 [0x15d50a3b0]
  Block size=512 [0x200]
Resize operation seems to have been successful


ubuntu@ubuntu:~$ sudo sg_readcap /dev/sg1
READ CAPACITY (10) indicates device capacity too large
  now trying 16 byte cdb variant
Read Capacity results:
   Protection: prot_en=0, p_type=0, p_i_exponent=0
   Logical block provisioning: lbpme=0, lbprz=0
   Last LBA=5860533167 (0x15d50a3af), Number of logical blocks=5860533168
   Logical block length=512 bytes
   Logical blocks per physical block exponent=0
   Lowest aligned LBA=0
Hence:
   Device size: 3000592982016 bytes, 2861588.5 MiB, 3000.59 GB, 3.00 TB
 
 
ubuntu@ubuntu:~$ sudo sg_format --resize --count=7814044224 /dev/sg1
    HITACHI   HUS72604CLAR3000  N9C0   peripheral_type: disk [0x0]
      << supports protection information>>
      Unit serial number: K4H6SXBB
      LU name: 5000cca25d44ae04
Mode Sense (block descriptor) data, prior to changes:
  <<< longlba flag set (64 bit lba) >>>
  Number of blocks=5860533168 [0x15d50a3b0]
  Block size=512 [0x200]
Try MODE SELECT again with SP=0 this time
MODE SELECT command: Illegal request
    try '-v' for more information
sg_format failed: Illegal request
ubuntu@ubuntu:~$ sudo sg_format --resize --count=5860533169 /dev/sg1
    HITACHI   HUS72604CLAR3000  N9C0   peripheral_type: disk [0x0]
      << supports protection information>>
      Unit serial number: K4H6SXBB
      LU name: 5000cca25d44ae04
Mode Sense (block descriptor) data, prior to changes:
  <<< longlba flag set (64 bit lba) >>>
  Number of blocks=5860533168 [0x15d50a3b0]
  Block size=512 [0x200]
Try MODE SELECT again with SP=0 this time
MODE SELECT command: Illegal request
    try '-v' for more information
sg_format failed: Illegal request
ubuntu@ubuntu:~$
I realize this thread a bit old but I've run into this exact same issue with a drive I got off Ebay. Did you ever find a solution to get it resized?
 

amp88

Member
Jul 9, 2020
59
63
18
I realize this thread a bit old but I've run into this exact same issue with a drive I got off Ebay. Did you ever find a solution to get it resized?
I never did, unfortunately. I'm still using them as 3TB drives in a backup KTN-STL3 enclosure, and they've been trouble free for the last ~10 months.
 
  • Like
Reactions: T_Minus

mrpburke

New Member
Sep 29, 2023
6
0
1
I never did, unfortunately. I'm still using them as 3TB drives in a backup KTN-STL3 enclosure, and they've been trouble free for the last ~10 months.
Thanks. I was afraid that was going to be the case.

I tried a few different things (sg_format and hugo) with no success so I'll just be keeping it as a 3TB drive. The ebay seller did give me a 50% refund which seemed fair.
 

mr44er

Active Member
Feb 22, 2020
135
43
28
That capacity clipping is a firmware-thing. You would need to force generic firmware over and this has different locks. If you find a free solution, I'm all ears.

Edit: Can you give me the output of smartctl -x -q noserial /dev/sdX ?
 
Last edited: