SAS Drive showing *more* space than expected?

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

Dave Corder

Active Member
Dec 21, 2015
298
194
43
41
I just received a couple of 10 TB HGST SAS drives (via eBay) to go in my TrueNAS server (nb: one of the mirrors that comprises my pool is a 8TB/10TB pair, so I wanted to swap out the 8TB drive to make it a pair of 10TB and gain a little more space).

Strangely, for the first drive I installed, smartctl shows that the drive is 10.5 TB, not 10 TB. I've never seen this before, and I can't find anything online about this, either. I'm well aware of the common issue of SAS drives showing less available space due to 520b sectors and needing to be reformatted as 512b to show the full capacity, but I've never seen it the other way around (and this drive is supposedly a 4kN drive and smartctl shows 4096b sectors).

Anyone have any ideas what this means?

Code: 
sudo smartctl -a /dev/sdbr
smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.15.131+truenas] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Vendor:               HGST
Product:              HUH721010AL4204
Revision:             C386
Compliance:           SPC-4
User Capacity:        10,511,707,983,872 bytes [10.5 TB]
Logical block size:   4096 bytes
LU is fully provisioned
Rotation Rate:        7200 rpm
Form Factor:          3.5 inches
Logical Unit id:      0x5000cca251036d40
Serial number:        ********
Device type:          disk
Transport protocol:   SAS (SPL-3)
Local Time is:        Fri Nov  3 17:52:40 2023 PDT
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

Grown defects during certification = 0
Total blocks reassigned during format = 0
Total new blocks reassigned = 0
Power on minutes since format = 871065
Current Drive Temperature:     35 C
Drive Trip Temperature:        85 C

Accumulated power on time, hours:minutes 33624:37
Manufactured in week 07 of year 2016
Specified cycle count over device lifetime:  50000
Accumulated start-stop cycles:  251
Specified load-unload count over device lifetime:  600000
Accumulated load-unload cycles:  1759
Elements in grown defect list: 0

Vendor (Seagate Cache) information
  Blocks sent to initiator = 2051918192967680

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     302428      14419.983           0
write:         0        0         0         0     464473      29247.545           0
verify:        0        0         0         0     339331          0.000           0

Non-medium error count:       39

SMART Self-test log
Num  Test              Status                 segment  LifeTime  LBA_first_err [SK ASC ASQ]
     Description                              number   (hours)
# 1  Background short  Completed                   -   33613                 - [-   -    -]
# 2  Background short  Completed                   -   33589                 - [-   -    -]
# 3  Background short  Completed                   -   33570                 - [-   -    -]

Long (extended) Self-test duration: 65535 seconds [1092.2 minutes]
 
D

Dave Corder

Active Member
Dec 21, 2015
298
194
43
41
mr44er said:
<- page 24

2441609216 * 4096 = 10000831348736

I think the sector size conversion 'onthefly/quick' was used and not every single one was reformatted. I don't know better, but I would reformat them to be on the safe side.
Yes, it will take ages. :)
Click to expand...
Thanks for that link - I was looking for something like that but just kept finding dead links.

Looks like someone just set the number of available blocks to something non-standard. No idea why...maybe it was something specific to a particular vendor's SAN, or someone wanted to get a tiny bit more space by sacrificing some of the blocks reserved for reallocations...who knows. TIL I learned that sg_format allows you to change that...

This disk:

Code: 
root@lcars[/mnt/media-01/home/root]# sdparm /dev/sdco --command=capacity
    /dev/sdco: HGST      HUH721010AL4204   C386
blocks: 2564414777
block_length: 4096
capacity_mib: 10017245.2
Another 10TB drive from the same family already in my pool:
Code: 
root@lcars[/mnt/media-01/home/root]# sdparm /dev/sdce --command=capacity
    /dev/sdce: HGST      HUH721010AL42C0   A3Z4
blocks: 2441609216
block_length: 4096
capacity_mib: 9537536.0
So now I'm currently running

sg_format /dev/sdco -F --size=4096 --count=2441609216

On one of the drives and that should get it back to where it's supposed to be. I *might* be able to get away with just a resize command versus a full format, but better safe than sorry...
 
  • Like
Reactions: homeserver78
D

Dave Corder

Active Member
Dec 21, 2015
298
194
43
41
Just a quick update for anyone who stumbles across this post in the future - the drives formatted just fine to the correct number of blocks, and I've successfully integrated them into my pool (no issues with that, other than I've got a couple other drives now developing bad sectors).
 
I

i386

Well-Known Member
Mar 18, 2016
4,251
1,548
113
34
Germany
mr44er said:
I think the sector size conversion 'onthefly/quick' was used and not every single one was reformatted. I don't know better, but I would reformat them to be on the safe side.
Click to expand...
I had this once with some husmm 200gb ssds that after formatting showed up as 15,8TB in diskpart :D
 
You must log in or register to reply here.
Top Bottom