8TB Sun/hgst drive showing as 7.9TB (and not 8.0TB like others)

[james23]

I have 7x 8tb HGST "he8" drives i had purchased from ebay. and then one 8tb SUN/HGST "he8" drive from ebay.

I need to use them in a 8x disk vDEV to add to my existing pool, however the 8tb SUN/HGST "he8" is showing about 140gb less space. (thus if i use it in my new vDEV, i will be forced to loose that same 150gb on all 8x disks, thus loosing around 900gb in aggregate )

Does anyone know if its possible for me to get this disk to show its proper 8.0TB like the other 7x disks?

so im pretty sure this is due to the drives unique firmware and/or related to 520b sector size vs standard 512b sector size. (is prob. a netapp disk or a custom/unique disk for some other SAN). But it shows as 512b in smartctl / diskinfo (see image or data below).

Im thinking about trying the steps in this post:
Repurposing netapp disk trays with FreeBSD and ZFS – Sysop.ca

but wanted to check here first to see if others have any input.

One thing i did try yesterday was this:

root@freenas:~ # sg_format -v --format --size=512 /dev/da44

(it took about 20-hours to complete, and the result was the exact same as before, ie still ~7.9tb , not 8.0tb).

anyone have any info/ideas? (or do i just need to bit the bullet and either take the~900gb hit, or else buy 1 more 8.0tb non sun hgst drive).

thanks!

comparisons of data from a "normal" 8tb i have, vs this "problem sun" 8tb. (same data is below in txt format):

**NORMAL DISK**

root@freenas:~ # diskinfo -v da43
da43
        512             # sectorsize
        8001563222016   # mediasize in bytes (7.3T)
        15628053168     # mediasize in sectors
        4096            # stripesize
        0               # stripeoffset
        972801          # Cylinders according to firmware.
        255             # Heads according to firmware.
        63              # Sectors according to firmware.
        HP MB8000JEQVA  # Disk descr.
        VLG1MYGV        # Disk ident.
        id1,enc@n5003048001eae9fd/type@0/slot@3/elmdesc@Slot_03 # Physical path
        No              # TRIM/UNMAP support
        7200            # Rotation rate in RPM
        Not_Zoned       # Zone Mode


Geom name: da42
Providers:
1. Name: da42
   Mediasize: 8001563222016 (7.3T)
   Sectorsize: 512
   Stripesize: 4096
   Stripeoffset: 0
   Mode: r0w0e0
   descr: HP MB8000JEQVA
   lunid: 5000cca254a7965c
   ident: VKJZ55MV
   rotationrate: 7200
   fwsectors: 63
   fwheads: 255


root@freenas:~ # smartctl -a /dev/da43
smartctl 6.6 2017-11-05 r4594 [FreeBSD 11.2-STABLE amd64] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Vendor:               HP
Product:              MB8000JEQVA
Revision:             HPDB
Compliance:           SPC-4
User Capacity:        8,001,563,222,016 bytes [8.00 TB]
Logical block size:   512 bytes
Physical block size:  4096 bytes
Rotation Rate:        7200 rpm
Form Factor:          3.5 inches
Logical Unit id:      0x5000cca26002fd0c
Serial number:        VLG1MYGV
Device type:          disk
Transport protocol:   SAS (SPL-3)


**PROBLEM SUN DISK**

root@freenas:~ # diskinfo -v da44
da44
        512             # sectorsize
        7865536647168   # mediasize in bytes (7.2T)
        15362376264     # mediasize in sectors
        4096            # stripesize
        0               # stripeoffset
        956263          # Cylinders according to firmware.
        255             # Heads according to firmware.
        63              # Sectors according to firmware.
        HGST H7280A520SUN8.0T   # Disk descr.
        001523PGHSUV        2EGGHSUV    # Disk ident.
        id1,enc@n5003048001eae9fd/type@0/slot@4/elmdesc@Slot_04 # Physical path
        No              # TRIM/UNMAP support
        7200            # Rotation rate in RPM
        Not_Zoned       # Zone Mode
Geom name: da44
Providers:
1. Name: da44
   Mediasize: 7865536647168 (7.2T)
   Sectorsize: 512
   Stripesize: 4096
   Stripeoffset: 0
   Mode: r0w0e0
   descr: HGST H7280A520SUN8.0T
   lunid: 5000cca23b1a618c
   ident: 001523PGHSUV        2EGGHSUV
   rotationrate: 7200
   fwsectors: 63
   fwheads: 255

root@freenas:~ # smartctl -a /dev/da44
smartctl 6.6 2017-11-05 r4594 [FreeBSD 11.2-STABLE amd64] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Vendor:               HGST
Product:              H7280A520SUN8.0T
Revision:             P9E2
Compliance:           SPC-4
User Capacity:        7,865,536,647,168 bytes [7.86 TB]
Logical block size:   512 bytes
Physical block size:  4096 bytes
Formatted with type 1 protection
LU is fully provisioned
Rotation Rate:        7200 rpm
Form Factor:          3.5 inches
Logical Unit id:      0x5000cca23b1a618c
Serial number:        001523PGHSUV        2EGGHSUV
Device type:          disk
Transport protocol:   SAS (SPL-3)
Local Time is:        Thu Sep  5 18:30:46 2019 CDT
SMART support is:     Available - device has SMART capability.
SMART support is:     Enabled
Temperature Warning:  Enabled

=== START OF READ SMART DATA SECTION ===
SMART Health Status: OK

camcontrol devlist of a good 8tb disk and this problem 8tb disk

root@freenas:~ # camcontrol devlist
...
<HGST H7280A520SUN8.0T P9E2>       at scbus8 target 40 lun 0 (da44,pass49)
<ATA HGST HUH728080AL GP23>        at scbus8 target 53 lun 0 (pass32,da27)

 

[marcoi]

Just a thought - any chance there is a hidden partition on the new drive? can you put the drive into another system and use a partition tool to double check?
I have had issues in the past using cmd lines in freenas to work with drives. So i put them into another system and use a different OS like windows to double check and or delete partitions, etc.

 

[james23]

Thanks for reply, i actually did check that before i did the low level format and there is none. I had been using this drive along with 3 others exactly like it in a different freenas server (where all 4x drives were the smaller size 7.9tb size).

also i would hope that (even if there was a hidden partition that 3x different OSes didnt show), doing this low level format should have wiped all of that (or correct me if im wrong pls):
root@freenas:~ # sg_format -v --format --size=512 /dev/da44

thanks

 

[Terry Kennedy]

anyone have any info/ideas? (or do i just need to bit the bullet and either take the~900gb hit, or else buy 1 more 8.0tb non sun hgst drive).

Formatted with type 1 protection

I think that is your problem - the drive still thinks it is using 520 byte sectors. Try adding --fmtpinfo=0 --pfu=0 to your sg_format command line.

 

[maes]

I think that is your problem - the drive still thinks it is using 520 byte sectors. Try adding --fmtpinfo=0 --pfu=0 to your sg_format command line.

Yeah from what I can read up that looks like some kind of funky 'built-in data protection' system where the drive internally adds a byte of CRC to every 512B sector, so it 'looks' like it's formatted in 512B, but each sector actually takes 520B of space on the drive itself.

 

[james23]

I think that is your problem - the drive still thinks it is using 520 byte sectors. Try adding --fmtpinfo=0 --pfu=0 to your sg_format command line.

Unbelievable that you picked that out from all the data i posted... but i think you have nailed it!

I should know in about 20 (!) hours and will def. update back here.

Even if it does not accomplish what i need, that has to be the issue im seeing.

Im actually pretty sure that smartctl -a output i posted was from *before* i ran
sg_format -v --format --size=512 /dev/da44

i say that as when i just now re-ran smartctl , it actually does not show that line any more:

root@freenas:~ # smartctl -a /dev/da44
smartctl 6.6 2017-11-05 r4594 [FreeBSD 11.2-STABLE amd64] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Vendor:               HGST
Product:              H7280A520SUN8.0T
Revision:             P9E2
Compliance:           SPC-4
User Capacity:        7,865,536,647,168 bytes [7.86 TB]
Logical block size:   512 bytes
Physical block size:  4096 bytes
LU is fully provisioned
Rotation Rate:        7200 rpm
Form Factor:          3.5 inches
Logical Unit id:      0x5000cca23b1a618c
Serial number:        001523PGHSUV        2EGGHSUV
Device type:          disk
Transport protocol:   SAS (SPL-3)
Local Time is:        Fri Sep  6 20:45:49 2019 CDT

Eitherway, off we go:

root@freenas:~ # sg_format -v --format --size=512 --fmtpinfo=0 --pfu=0 /dev/da44
    HGST      H7280A520SUN8.0T  P9E2   peripheral_type: disk [0x0]
      PROTECT=1
      << supports protection information>>
      Unit serial number: 001523PGHSUV        2EGGHSUV
      LU name: 5000cca23b1a618c
    mode sense (10) cdb: 5a 00 01 00 00 00 00 00 fc 00
Mode Sense (block descriptor) data, prior to changes:
Mode sense number of blocks maxed out, set longlba
    mode sense (10) cdb: 5a 10 01 00 00 00 00 00 fc 00
Mode Sense (block descriptor) data, prior to changes:
  <<< longlba flag set (64 bit lba) >>>
  Number of blocks=15362376264 [0x393ab4248]
  Block size=512 [0x200]

A FORMAT UNIT will commence in 15 seconds
    ALL data on /dev/da44 will be DESTROYED
        Press control-C to abort

A FORMAT UNIT will commence in 10 seconds
    ALL data on /dev/da44 will be DESTROYED
        Press control-C to abort

A FORMAT UNIT will commence in 5 seconds
    ALL data on /dev/da44 will be DESTROYED
        Press control-C to abort
    format unit cdb: 04 18 00 00 00 00

Format unit has started
Format in progress, 0.11% done
Format in progress, 0.27% done

Some more info / copy/paste on these sb_format arguments:

Spoiler: extra info

Recent SBC-3 drafts add several "protection types" to the "protection information" introduced in the SBC-2 standard. See the "protection information" section (section 4.18 in draft SBC-3 rev 18). 8 bytes of protection information are added to each block (a 2 byte "logical block guard" (CRC), a 2 byte "logical block application guard", and a 4 byte "logical block reference tag"). A device that supports protection information sets the "PROTECT" bit in its standard INQUIRY response. The "FMTPINFO" field in in the FORMAT UNIT command cdb plus the "Protection Field Usage" in the parameter header are associated with protection information and can be set by this utility.

(from: sg_format(8): format/resize SCSI disk - Linux man page)

man page data for these arguments:

-f, --fmtpinfo=FPI
sets the FMTPINFO field in the FORMAT UNIT cdb to a value between 0 and 3. The default value is 0. The FMTPINFO field from SBC-3 revision 16 is a 2 bit field (bits 7 and 6 of byte 1 in the cdb). Prior to that it was a single bit field (bit 7 of byte 1 in the cdb) and there was an accompanying bit called RTO_REQ (bit 6 of byte 1 in the cdb). The deprecated options "--pinfo" and "--rto-req" represent the older usage. This option should be used in their place. This option has no action unless --format is given.


-P, --pfu=PFU
sets the "Protection Field Usage" field in the parameter block associated with a FORMAT UNIT command to PFU. The default value is 0, the only other defined value currently is 1. Used together with --fmtpinfo=FPI to specify the "protection type" to format the disk to (see SBC-3).

 

[maes]

Now I'm not all that familiar with sg commands so I'm just going off the man pages, so getting someone else to confirm/refute would be best before going forward with these commands.

Something that might also be worth trying would be:

sg_readcap -l /dev/da44

to get a bit more information (post output here)


This second one should (in theory) forcibly reset the number of sectors reported by the drive if there was an odd limit put in place.

sg_format --resize --count=-1 /dev/da44


I vaguely remember something about a way for OEMs to create completely 'hidden' areas on drives that aren't visible to some low-level commands but I can't remember the details. It might be the situation here. There are ways to unlock those areas.

 

[james23]

Thanks for all the replies / help.

It does still look like the drive is showing reduced capacity (ie still ~7.9tb , exactly like before , after running:
sg_format -v --format --size=512 --fmtpinfo=0 --pfu=0 /dev/da44 (still shwoing 7.9tb)
so i then did a quick wipe via freenas gui (still 7.9tb)


So finally, i ran sg_format --resize --count=-1 /dev/da44
which returned an Illegal Request.

(i did also power cycle the drive, and again tried a quick wipe , and again: sg_format --resize --count=-1 /dev/da44
same result).

SUN is not going to make this easy (or possible). anyone have any thoughts or ideas? (much appreciated as always)

output:

root@freenas:~ # sg_format -v --format --size=512 --fmtpinfo=0 --pfu=0 /dev/da44
    HGST      H7280A520SUN8.0T  P9E2   peripheral_type: disk [0x0]
      PROTECT=1
      << supports protection information>>
      Unit serial number: 001523PGHSUV        2EGGHSUV
      LU name: 5000cca23b1a618c
    mode sense (10) cdb: 5a 00 01 00 00 00 00 00 fc 00
Mode Sense (block descriptor) data, prior to changes:
Mode sense number of blocks maxed out, set longlba
    mode sense (10) cdb: 5a 10 01 00 00 00 00 00 fc 00
Mode Sense (block descriptor) data, prior to changes:
  <<< longlba flag set (64 bit lba) >>>
  Number of blocks=15362376264 [0x393ab4248]
  Block size=512 [0x200]

A FORMAT UNIT will commence in 15 seconds
    ALL data on /dev/da44 will be DESTROYED
        Press control-C to abort

A FORMAT UNIT will commence in 10 seconds
    ALL data on /dev/da44 will be DESTROYED
        Press control-C to abort

A FORMAT UNIT will commence in 5 seconds
    ALL data on /dev/da44 will be DESTROYED
        Press control-C to abort
    format unit cdb: 04 18 00 00 00 00

Format unit has started
Format in progress, 0.11% done
Format in progress, 0.27% done
...
Format in progress, 99.77% done
Format in progress, 99.89% done
FORMAT UNIT Complete



root@freenas:~ # smartctl -a /dev/da44
smartctl 6.6 2017-11-05 r4594 [FreeBSD 11.2-STABLE amd64] (local build)
Copyright (C) 2002-17, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Vendor:               HGST
Product:              H7280A520SUN8.0T
Revision:             P9E2
Compliance:           SPC-4
User Capacity:        7,865,536,647,168 bytes [7.86 TB]
Logical block size:   512 bytes
Physical block size:  4096 bytes
LU is fully provisioned
Rotation Rate:        7200 rpm
Form Factor:          3.5 inches
Logical Unit id:      0x5000cca23b1a618c
Serial number:        001523PGHSUV        2EGGHSUV
Device type:          disk
Transport protocol:   SAS (SPL-3)
Local Time is:        Sat Sep  7 13:27:20 2019 CDT
SMART support is:     Available - device has SMART capability.
SMART support is:     Enabled
Temperature Warning:  Enabled

=== START OF READ SMART DATA SECTION ===
SMART Health Status: OK

Current Drive Temperature:     39 C
Drive Trip Temperature:        85 C

Manufactured in week 23 of year 2015
Specified cycle count over device lifetime:  50000
Accumulated start-stop cycles:  13
Specified load-unload count over device lifetime:  600000
Accumulated load-unload cycles:  1178
Elements in grown defect list: 0

Vendor (Seagate) cache information
  Blocks sent to initiator = 72392146539249664

Error counter log:
           Errors Corrected by           Total   Correction     Gigabytes    Total
               ECC          rereads/    errors   algorithm      processed    uncorrected
           fast | delayed   rewrites  corrected  invocations   [10^9 bytes]  errors
read:          0        0         0         0     630683     107218.382           0
write:         0        0         0         0    2018468     162318.916           0
verify:        0        0         0         0      19372          0.000           0

Non-medium error count:        0

No self-tests have been logged

root@freenas:~ #

sg_readcap -l output:

root@freenas:~ # sg_readcap -l /dev/da44
Read Capacity results:
   Protection: prot_en=0, p_type=0, p_i_exponent=0
   Logical block provisioning: lbpme=0, lbprz=0
   Last logical block address=15362376263 (0x393ab4247), Number of logical blocks=15362376264
   Logical block length=512 bytes
   Logical blocks per physical block exponent=3 [so physical block length=4096 bytes]
   Lowest aligned logical block address=0
Hence:
   Device size: 7865536647168 bytes, 7501160.3 MiB, 7865.54 GB
root@freenas:~ #
root@freenas:~ #

** VS A PROPER 8TB: **

root@freenas:~ # sg_readcap -l /dev/da43
Read Capacity results:
   Protection: prot_en=0, p_type=0, p_i_exponent=0
   Logical block provisioning: lbpme=0, lbprz=0
   Last logical block address=15628053167 (0x3a3812aaf), Number of logical blocks=15628053168
   Logical block length=512 bytes
   Logical blocks per physical block exponent=3 [so physical block length=4096 bytes]
   Lowest aligned logical block address=0
Hence:
   Device size: 8001563222016 bytes, 7630885.3 MiB, 8001.56 GB
root@freenas:~ #

sg_format --resize --count=-1 /dev/da44 output:

root@freenas:~ # sg_format --resize --count=-1 /dev/da44
    HGST      H7280A520SUN8.0T  P9E2   peripheral_type: disk [0x0]
      << supports protection information>>
      Unit serial number: 001523PGHSUV        2EGGHSUV
      LU name: 5000cca23b1a618c
Mode Sense (block descriptor) data, prior to changes:
Mode Sense (block descriptor) data, prior to changes:
  <<< longlba flag set (64 bit lba) >>>
  Number of blocks=15362376264 [0x393ab4248]
  Block size=512 [0x200]
MODE SELECT command: Illegal request
    try '-v' for more information
root@freenas:~ #
** I TRIED IT AGAIN, WITH THE -V AS SUGGESTED, SAME RESULT BUT MORE INFO**

root@freenas:~ # sg_format -v --resize --count=-1 /dev/da44
    HGST      H7280A520SUN8.0T  P9E2   peripheral_type: disk [0x0]
      PROTECT=1
      << supports protection information>>
      Unit serial number: 001523PGHSUV        2EGGHSUV
      LU name: 5000cca23b1a618c
    mode sense (10) cdb: 5a 00 01 00 00 00 00 00 fc 00
Mode Sense (block descriptor) data, prior to changes:
Mode sense number of blocks maxed out, set longlba
    mode sense (10) cdb: 5a 10 01 00 00 00 00 00 fc 00
Mode Sense (block descriptor) data, prior to changes:
  <<< longlba flag set (64 bit lba) >>>
  Number of blocks=15362376264 [0x393ab4248]
  Block size=512 [0x200]
    mode select (10) cdb: 55 11 00 00 00 00 00 00 22 00
mode select (10):
Descriptor format, current; Sense key: Illegal Request
Additional sense: Parameter list length error
  Descriptor type: Information:    >> descriptor too short
    00 00 00 00 00 00 00 00 00 00
  Descriptor type: Command specific: 0x0000000000000000
  Descriptor type: Sense key specific: Field pointer:
        Error in Command: byte 7
  Descriptor type: Field replaceable unit code: 0x20
  Descriptor type: Block commands: Incorrect Length Indicator (ILI) clear
  Descriptor type: Vendor specific [0x80]
    MODE SELECT command: Illegal request sense key, apart from Invalid opcode

EDIT: I tried two more commands, with no success (and exact same output as above):
sg_format -v --resize --six --count=-1 /dev/da44
sg_format -v --resize --count=15628053168 /dev/da44
(15628053168 i took from a good 8.0tb hgst drive, ie /dev/da43)

also as a note/reference for others in future- here is a great related thread , i have read through all 8 pages of it, we seem to be trying to right things in this thread.
https://forums.servethehome.com/ind...ormat-hdd-ssd-to-512b-sector-size.4968/page-5

here is someone who had the exact same issue as I (different drive though), and was able to fix it via sg_format -r --count=1953525168 /dev/sgX (-r = --resize)
https://forums.servethehome.com/ind...d-to-512b-sector-size.4968/page-6#post-199768

 

[gseeley]

This might be an issue with Freenas. I was able to use similar tools on a Proxmox 6.0 (Debian) box to fix the same disks. This was using an LSI SAS3008 HBA as well.

Formatted to 512 byte sectors with:

# sg_format --format --size=512 -v -e /dev/sg0

Size after format:

# sg_readcap /dev/sg0
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=15362376263 (0x393ab4247), Number of logical blocks=15362376264
   Logical block length=512 bytes
   Logical blocks per physical block exponent=3 [so physical block length=4096 bytes]
   Lowest aligned LBA=0
Hence:
   Device size: 7865536647168 bytes, 7501160.3 MiB, 7865.54 GB, 7.87 TB

Resized with:

# sg_format --resize --count=-1 /dev/sg0
    HGST      H7280A520SUN8.0T  P554   peripheral_type: disk [0x0]
      << supports protection information>>
      Unit serial number: 001526PKVPXV        2EGKVPXV
      LU name: 5000cca23b207a40
Mode Sense (block descriptor) data, prior to changes:
  <<< longlba flag set (64 bit lba) >>>
  Number of blocks=15362376264 [0x393ab4248]
  Block size=512 [0x200]
Resize operation seems to have been successful

Size after resize:

# sg_readcap /dev/sg0
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=15628053167 (0x3a3812aaf), Number of logical blocks=15628053168
   Logical block length=512 bytes
   Logical blocks per physical block exponent=3 [so physical block length=4096 bytes]
   Lowest aligned LBA=0
Hence:
   Device size: 8001563222016 bytes, 7630885.3 MiB, 8001.56 GB, 8.00 TB

Bonus, permanently enabled drive write cache:

# dmesg | grep sda | grep "Write cache:"
[    6.568272] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, supports DPO and FUA

# sdparm /dev/sg0 | grep WCE
  WCE           0  [cha: y, def:  0, sav:  0]
# sdparm -s WCE -S /dev/sg0
    /dev/sg0: HGST      H7280A520SUN8.0T  P554
# sdparm /dev/sg0 | grep WCE
  WCE           1  [cha: y, def:  0, sav:  1]
# smartctl -x /dev/sg0 | grep "Write"
Writeback Cache is:   Enabled

This worked on all four H7280A520SUN8.0T I have.

 

[james23]

interesting gseely! i already have the 20x or so of these drives in use at the 7.9tb size (or really more like 7.825tb size). so your reply/steps will help when i get a chance to move them around.

i also wanted to post this web link/tool i came across recently for something unrelated to this;

Change blocksize of SCSI disks

Change blocksize of SCSI disks

micha.freeshell.org

the tool looks very old, and i have NOT used or tried it yet, but claims it can specifically:

[resize] a disk from an IBM machine that uses 520Byte/block or 524Byte/block for a standard PC. setblocksize reformats the disk to a blocksize of 512Byte

so i figured i would post that link here for others (and for my future self!)

 

[tntlt]

even i did all recommended steps for my HGST 8TB disk it still mounts only 7.3TB:

/dev/sda                           7.3T   93M  7.3T   1% /mnt/sas01

and there is sg_readcap:

# sg_readcap -l /dev/sda
Read Capacity results:
   Protection: prot_en=0, p_type=0, p_i_exponent=0
   Logical block provisioning: lbpme=0, lbprz=0
   Last LBA=15628053167 (0x3a3812aaf), Number of logical blocks=15628053168
   Logical block length=512 bytes
   Logical blocks per physical block exponent=3 [so physical block length=4096 bytes]
   Lowest aligned LBA=0
Hence:
   Device size: 8001563222016 bytes, 7630885.3 MiB, 8001.56 GB, 8.00 TB

 

[BlueFox]

That's expected and you're not having the same problem as the OP (or really any problem for that matter). Base 2 vs base 10 method of counting size. You can see that your disk is 8 trillion bytes unlike what the OP of this thread posted (which was ~7.87 trillion bytes).

 

[tntlt]

I got one disk which I still cannot resize. I reformat it then i resized it multiple times and still the same. Any thoughts ?

# sg_format --resize --count=-1 /dev/sg4
    HGST      H7280B520SUN8.0T  A3Y1   peripheral_type: disk [0x0]
      << supports protection information>>
      Unit serial number: 001838SL4HMU        7SJL4HMU
      LU name: 5000cca25291ba60
Mode Sense (block descriptor) data, prior to changes:
  <<< longlba flag set (64 bit lba) >>>
  Number of blocks=15362376264 [0x393ab4248]
  Block size=512 [0x200]
Resize operation seems to have been successful

# sg_readcap /dev/sg4
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=15362376263 (0x393ab4247), Number of logical blocks=15362376264
   Logical block length=512 bytes
   Logical blocks per physical block exponent=3 [so physical block length=4096 bytes]
   Lowest aligned LBA=0
Hence:
   Device size: 7865536647168 bytes, 7501160.3 MiB, 7865.54 GB, 7.87 TB

I found the differences - the disk which is able to resize to 8TB:

Vendor:               HGST
Product:              H7280A520SUN8.0T
Revision:             P901
Compliance:           SPC-4
User Capacity:        8,001,563,222,016 bytes [8.00 TB]

and there is picky one with a diff product and revision:

Vendor:               HGST
Product:              H7280B520SUN8.0T
Revision:             A3Y1
Compliance:           SPC-4
User Capacity:        7,865,536,647,168 bytes [7.86 TB]

I wonder if there is a firmware for these hardisks to get more manageable?

 

[itronin]

I got one disk which I still cannot resize. I reformat it then i resized it multiple times and still the same. Any thoughts ?

I've had some Sun 8TB drives that would not resize at 512b LB, I changed to 4096 LB and reformatted. Drive finally had the correct capacity. Not saying that's a fix for your problem just relating a similar situation and how I resolved it.

 

[tntlt]

Thanks! Helped, now i need re-format all to size 4096.

 

[Terry Kennedy]

I've had some Sun 8TB drives that would not resize at 512b LB, I changed to 4096 LB and reformatted. Drive finally had the correct capacity. Not saying that's a fix for your problem just relating a similar situation and how I resolved it.

HGST has a rather unclear note on their 4Kn drive labels: This HDD has reduced LBA counts if formatted as 512B + T10 PI (8 bytes).

That seems to imply you get the nameplate capacity if you reformat to plain old 512, but lose capacity if you format it to 520. But you also lose capacity by reformatting from 4096 to plain old 512 as well. Which makes sense as much of the sector overhead is constant regardless of sector size, although I believe that the larger sectors have more complex (larger) ECC as well.

I've looked at the OEM spec for the HUH728080AL4200 drive and it doesn't have a nice table showing the LBA capacity at 4096, 512 and 520. Given that the vast majority of those drives shipped with modified firmware and labeling for specific OEMs, the LBA capacity was probably also modified (companies like Dell, HPE and others want all of their "8TB" drives to have the same LBA capacity regardless of manufacturer or model) so having a table in the OEM manual probably wasn't thought to be useful.

 

[Whaaat]

I've looked at the OEM spec for the HUH728080AL4200 drive and it doesn't have a nice table showing the LBA capacity at 4096, 512 and 520.

It took me about 20 seconds to find this info

Spoiler: capacity

 

[Terry Kennedy]

It took me about 20 seconds to find this info

Thanks! That is a much newer version of the OEM manual than the one I have.

 

[AU8830]

I recently bought some Sun-branded HGST HUH728080AL5200 8TB drives (firmware indicates model as H7280A520SUN8.0T with firmware version P901) and also ran into them being identified as 7.86TB capacity, rather than 8.0TB. I initially thought that they just needed to be formatted to 512 rather than the default 520 sector size, but it appears that even when formatted as 512e, firmware still uses 520 byte sectors and reports 512 (or they're really 512 sectors but the sector count has a limit?).

The only way to get them to show the full 8TB is format them as 4kn. I initially tried sg_format, but it would only allow formatting with 512 byte - any attempt to format or resize as 4096 byte would result in an error (tried various permutations of the format and resize commands). sg_format worked correctly if you specified 512 sector size, but as described, it behaves like 520 sectors.

I got around this by using the following utility:

GitHub - ahouston/setblocksize: Fork of setblocksize

Fork of setblocksize. Contribute to ahouston/setblocksize development by creating an account on GitHub.

github.com

setblocksize -b4096 /dev/sgX

That utility indicated that the resize completed successfully, and the drive indicator light stopped flashing after 12 or so hours, but the drive was not actually usable at that stage. It would report SMART information using smartctl from smartmontools, but the status was "not ready".

I then used:
sg_format --format /dev/sgX

and after another 12 hours, the drive was up and running at full 8TB capacity, as a 4kn drive.

I'm using an M1015 running IT firmware. I've read a few reports about 4kn only working on LSI SAS2308 and later, but the drives seem to work fine with the IT firmware on the older cards - they appear in the MPT BIOS and work fine (successfully written to the full disk) in Linux. I'm using Ubuntu 18.04 with kernel 4.15.

 

[skorpioskorpio]

Hmm, interesting I had a similar issue with a Seagate ST2000LM007, I had one drive that reported like 10% less capacity than many others. It also reported different firmware although all the same revision numbers for everything else. In my impatient attempt to cut to the chase, I had a flakey dead drive and I swapped the electronics, and that solved the odd capacity problem in that it killed that drive stone dead, and it's electronics did the same to the other. So there you go, problem solved no more flaky drive and no more undersized drive, both are just drink coasters now.

Shoulda read this thread a month ago I guess.