Other Deciding what to do with 520byte sector size SSD

zeRusski

zeRusski

Hello Forum. I find myself the owner of this wonderful thing here:
Code: 
$ sudo diskinfo -v da7
da7
        520             # sectorsize
        1600321314800   # mediasize in bytes (1.5T)
        3077540990      # mediasize in sectors
        4160            # stripesize
        0               # stripeoffset
        191568          # Cylinders according to firmware.
        255             # Heads according to firmware.
        63              # Sectors according to firmware.
        HITACHI HUSMM141CLAR1600        # Disk descr.
        0SYBE15A                # Disk ident.
        Yes             # TRIM/UNMAP support
        0               # Rotation rate in RPM
        Not_Zoned       # Zone Mode
Yep, 520byte sector size. Suddenly I face dilemma. What should I do with it? Quick googling around shows the entire interwebs and their dog trying to hivemind how to reformat this and that drive pulled out of a server from 520 byte sector size to 512. First, I've no idea what those sectors even mean. Or alignment or whatever. Until this moment I've been blissfully unaware (or blatantly ignored their mention in manpages) of all this nonsense: there is a drive, it has size, we put a filesystem on it - the end.

All the stories about getting those to 512 bytes I've seen reek of cargoculting and magic - some bizarre voodoo practices with little understanding behind them.

Do I even need to bother?
Should I just try to `gpart` this thing, `newfs` it and leave those poor fat sectors alone?
Will my FreeBSD-here-machine put anathema on my arse if I try anything but 512byte sectorsize?
Are there any big wins to be had here?
If so then how do I go about doing that on FreeBSD?
Also be nice to maybe make sense of all this block, sector, etc nonsense. Any pointers there?

Thanks
 
oh god there's apparently `logical` blocksize vs `physical` blocksize. I've no clue what's what, what it all means and to which manpages refer when they mention a block size. Looking at you newfs(8)()
 
zeRusski said:
well ... you did mention sector size `newfs` so wtf yourself
Click to expand...
oh wait it actually complains about the disk and looks like completely ignores the fact that I told it about sector size `-S 520` there is ignored. I get the same error if I drop that flag. Wtf indeed ... so is that why people re-format those drives to 512 byte sectors? Basically nothing works with 520?
 
Before partitioning you need to reformat with the correct sector size, e.g. 512 bytes.
I had to do this a few years ago with a bunch of Netapp drives to make them usable.
 
Snurg said:
Before partitioning you need to reformat with the correct sector size, e.g. 512 bytes.
I had to do this a few years ago with a bunch of Netapp drives to make them usable.
Click to expand...
wait what ... what's that mean? It isn't in the Storage chapter of the Handbook. Like camcontrol format or smth? Or the `sg_utils` you mentioned? Can I format with 520 sector size? Do you actually mean partitioning (gpart) or creating a filesystem?
 
512 byte is 2^9 bytes, this aligns well.
520 or 528 bytes sector size, no idea why Netapp, EMC etc use this.
Maybe for checksums?
Or is this just a means to prevent customers/users to purchase cheap disks from the street market?
 
Snurg said:
512 byte is 2^9 bytes, this aligns well.
520 or 528 bytes sector size, no idea why Netapp, EMC etc use this.
Maybe for checksums?
Or is this just a means to prevent customers/users to purchase cheap disks from the street market?
Click to expand...
appears that after re-formatting to 512 bytes I somehow "lost space". `gpart add` without size leaves 23G of space unallocated for some odd reason.
 
zeRusski said:
appears that after re-formatting to 512 bytes I somehow "lost space". `gpart add` without size leaves 23G of space unallocated for some odd reason.
Click to expand...
Thats interesting. On HDDs data is stored in analog magnetic tracks, the gaps become a bit longer when the data sectors get shorter.

But on SSD one would expect that the firmware would reorder and align with memory pages.
On the other hand, the type of your Hitachi SSD cannot be found neither with Google nor on the Hitachi Storage site.
So it is very probably that it is an OEM SSD designed to work with 520 byte sectors, and does not realign storage according to the chosen sector size.
So you got the same capacity loss that everybody gets when reformatting a 520byte HDD to 512 Byte.

But it usually pays off, as the 520byte drives are usually very cheap second hand.
 
Big question now is how the hell am I supposed to figure the health (e.g. its TBW or PBW) of this drive when all smartctl reports is this:
Code: 
$ sudo smartctl -t long -a /dev/da7
smartctl 7.2 2020-12-30 r5155 [FreeBSD 12.2-RELEASE amd64] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Vendor:               HITACHI
Product:              HUSMM141CLAR1600
Revision:             C342
Compliance:           SPC-4
User Capacity:        1,600,321,314,816 bytes [1.60 TB]
Logical block size:   512 bytes
Physical block size:  4096 bytes
LU is resource provisioned, LBPRZ=1
Rotation Rate:        Solid State Device
Form Factor:          2.5 inches
Logical Unit id:      0x5000cca050bdde24
Serial number:        0SYBE15A
Device type:          disk
Transport protocol:   SAS (SPL-3)
Local Time is:        Mon Mar 15 22:27:49 2021 GMT
SMART support is:     Available - device has SMART capability.
SMART support is:     Enabled
Temperature Warning:  Disabled or Not Supported

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

Percentage used endurance indicator: 0%
Current Drive Temperature:     31 C
Drive Trip Temperature:        65 C

Accumulated power on time, hours:minutes 17846:19
Manufactured in week 42 of year 2017
Specified cycle count over device lifetime:  0
Accumulated start-stop cycles:  0
Specified load-unload count over device lifetime:  0
Accumulated load-unload cycles:  0
Elements in grown defect list: 0

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

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          0          0.002           0
write:         0        0         0         0          0          0.250           0

Non-medium error count:        0

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

Long (extended) Self-test duration: 6 seconds [0.1 minutes]

Long (extended) offline self test failed [unsupported field in scsi command]

Is there anything better on FreeBSD? Some other way to figure TBW of an SSD? Kind of a different topic ... maybe I should move into separate thread
 
SCSI/SAS drives have very limited SMART info.
If you have a Windows machine, you can try with Seatools. But that shows even less.
I don't know of anything showing more than smartmontools.
 
Snurg said:
512 byte is 2^9 bytes, this aligns well. 520 or 528 bytes sector size, no idea why Netapp, EMC etc use this.
Maybe for checksums?
Click to expand...
I guess so.
Snurg said:
Or is this just a means to prevent customers/users to purchase cheap disks from the street market?
Click to expand...
2nd advantage. You want our special, well tested & proven storage shelf, then you have to pay special prices, too. Makes sense. Especially since they compete on the prices that the customers pay initialy on purchasing the shelf, the vendors split off some of their margin into follow-up deals.
 
zeRusski said:
Hello Forum. I find myself the owner of this wonderful thing here:
Code: 
$ sudo diskinfo -v da7
da7
        520             # sectorsize
        1600321314800   # mediasize in bytes (1.5T)
        3077540990      # mediasize in sectors
        4160            # stripesize
        0               # stripeoffset
        191568          # Cylinders according to firmware.
        255             # Heads according to firmware.
        63              # Sectors according to firmware.
        HITACHI HUSMM141CLAR1600        # Disk descr.
        0SYBE15A                # Disk ident.
        Yes             # TRIM/UNMAP support
        0               # Rotation rate in RPM
        Not_Zoned       # Zone Mode
Yep, 520byte sector size. Suddenly I face dilemma. What should I do with it? Quick googling around shows the entire interwebs and their dog trying to hivemind how to reformat this and that drive pulled out of a server from 520 byte sector size to 512. First, I've no idea what those sectors even mean. Or alignment or whatever. Until this moment I've been blissfully unaware (or blatantly ignored their mention in manpages) of all this nonsense: there is a drive, it has size, we put a filesystem on it - the end.

All the stories about getting those to 512 bytes I've seen reek of cargoculting and magic - some bizarre voodoo practices with little understanding behind them.

Do I even need to bother?
Should I just try to `gpart` this thing, `newfs` it and leave those poor fat sectors alone?
Will my FreeBSD-here-machine put anathema on my arse if I try anything but 512byte sectorsize?
Are there any big wins to be had here?
If so then how do I go about doing that on FreeBSD?
Also be nice to maybe make sense of all this block, sector, etc nonsense. Any pointers there?

Thanks
Click to expand...
It's sort of a misnomer the term "sectorsize" when in reality it's more like "blocksize". Sectorsize is preset by the manufacturer in their firmware. I guess it's a nomenclature thing.
Also the extra 8 bytes are the Data Integrity Field and has been in place for various storage mediums for a long time. I've seen it from Sun, HP, IBM, Hitachi, Samsung to name a few. SSD/SAS/SCSI etc.
 
OK, let's go to the basics. 520- and 528-byte disks have existed for ages, probably since the 70s. They probably were more common than 512-byte sector disks until the PC revolution. The extra bytes can store all manner of things, such as checksums, keys (for CKD data), metadata that links the content (not uncommon in databases), and so on. There are also block sizes that are a little bigger than 4K, for the same reasons. Quite a few industrial-strength disk systems use them.

Today, many industrially used disks are instead formatted using T10-DIF, which also stores checksums on disk. That is kinda sorta similar to having 520-byte blocks, but only kinda sorta. Also, a lot of file systems (such as ZFS) use checksums, but they do something smarter than 520-byte blocks or T10-DIF, they store the checksums AWAY from the data. That allows them to detect when a whole block write has gone missing (data and checksum).

All these technologies add real value, and aren't just a scam to charge customers more.

If you don't understand what sectors, logical blocks, and physical blocks are, you should probably read the Wikipedia pages about disks. Really quick: At the interface level, the drivers read/write whole logical blocks. Some disks internally aggregate logical blocks of 512 bytes into physical blocks of 4096 blocks. The word "sector" really shouldn't be used at the interface level, since it can easily be confused with logical block (the unit of atomic data transfer) and physical blocks (the unit of atomic IO).

I know no common open source file system that can make use of disks with block sizes other than 512 or 4096 bytes (candidates include ZFS, UFS, ext2/3/4, XFS. I vaguely remember that btrfs played with it.

Many (spinning rust) SCSI disks (today SCSI means mostly SAS) can be formatted at these block sizes. For SSDs, this is hit or miss; you seem to have gotten lucky. This requires a format command, which can be issued either by sg3_utils (typically on linux, but can be installed on FreeNSD), or by the FreeBSD native camcontrol utility.

Finally: SCSI SMART is, in my not at all humble opinion, actually better then SATA SMART. The SATA version gives you lots of counters, which move in all manners of directions. Nice toy. Except that it is really hard to tell when the disk is failing; you have to make up your own heuristics. SCSI SMART instead gives you a few important counters, plus one bit that is absolutely vital: The PFA bit, which tells you that the disk (in its own opinion) is predicting failure. Different disk models return PFA in different fashions, please read the SCSI manuals for your particular disk.

And always note that SMART is just one part of a strategy to deal with failing disks. Not all disks that fail get a SMART warning before hand; not all disks that SMART says should fail do actually fail. The SMART failure prediction is strongly correlated with actual failure, but not identical.
 
Snurg said:
SCSI/SAS drives have very limited SMART info.
If you have a Windows machine, you can try with Seatools. But that shows even less.
I don't know of anything showing more than smartmontools.
Click to expand...
For SCSI drives, the full data should be in the modepages (there should be a couple of them). These do usually contain a lot more than what smartctl extracts.
This is accessible with camcontrol modepage - but for the more delicate features one would need the technical manual from the manufacturer.
This is how it looks on a real (old) SCSI drive:
Code: 
# camcontrol modepage /dev/da1 -m 0x03 # page 3 - formatting info
Tracks per Zone:  4893
Alternate Sectors per Zone:  0
Alternate Tracks per Zone:  0
Alternate Tracks per Logical Unit:  0
Sectors per Track:  658
Data Bytes per Physical Sector:  512
Interleave:  1
Track Skew Factor:  20
Cylinder Skew Factor:  27
# camcontrol modepage /dev/da1 -m 0x1a # page 26 - power saving modes
PM_BG_PRECEDENCE:  0
STANDBY_Y:  0
IDLE_C:  0
IDLE_B:  0
IDLE_A:  0
STANDBY_Z:  0
IDLE_A Condition Timer:  0
STANDBY_Z Condition Timer:  0
 
You must log in or register to reply here.
Back
Top