-
Notifications
You must be signed in to change notification settings - Fork 67
Format, Fast Format, And Sector Sizes
There is a lot of misinformation, bad information, and out of date information spread around the web when it comes to formatting drives and how sector sizes impact usability and performance.
This page will provide up to date and accurate information as well as provide information about when old information came about.
Before getting too far the term format must be defined.
In the context of this Wiki the term format means performing a device configuration changing command that instructs the device firmware to rewrite the layout of the disk sectors before use.
The reason this must be defined this way is the internet is full of using the term format for other meanings: Erasing user data, writing a new file system to the device. Sometimes the internet uses low level format as what this wiki is defining format to mean, however it has also been seen to mean erasing user data.
Is the internet wrongly using format? These uses of format are not entirely wrong...but the history has been forgotten. So lets talk history briefly to understand why the term format is often used for these other meanings. Starting at the beginning of time (PCs): The floppy disk.
Wait a second, floppy disks? Not HDDs or SSDs?
Yep, floppy disks and floppy drives required the same thing: formatting. When HDDs became viable for use is PCs (the small form factor of 5.25" and smaller instead of 8" or larger) they picked up the same method of formatting not only due to the very similar use of a spinning medium, but also because HDDs were designed to be drop-in replacements with minimal other hardware or software changes.
When formatting floppy disks or old HDDs, it was done by providing an interleave buffer which described the layout of the sector numbers on a given track and to mark the sector as good, unassign alternate, assign alternate, or bad block. Some devices may not support alternate locations or have too few alternate locations so marking a block as bad was another way to inform the filesystem of where it was acceptable to store date or which sectors to skip. (more about interleaving later)
The way the drive controller would process the format request was to write to each sector which would also erase the data that was previously kept here. This is the primary reason the term format became synonymous with erase and is the root of why it is still used today to talk about erasing data. Keep in mind that just because a term is "popular" does not mean it is the most accurate term to use. IEEE 2883r2022 uses sanitize purge and sanitize clear as much better terms for use when talking about removing user data as format still has one other common meaning on the internet and in computing.
When installing a new HDD or even old floppy disks you would first need to format them, which wrote zeroes, but you were also asking to write a file system to the drive that your OS understands how to access for your use. Here is where the other definition of format comes from and can still be found in Windows operating systems today: writing a file system (exFAT, FAT32, NTFS, etc) to the device so that you can easily store your files to read and write.
In modern operating systems, the low-level process of providing an interleave and instructing the drive to go format each track one at a time no longer occurs (unless you are still using a floppy drive). For USB thumbdrives, HDDs, SSDs of today the software you are using to "format" the drive is simply writing a MBR or GPT followed by your requested type of file system.
While this seems like to most common use of these terms, why define it for this wiki? Well for openSeaChest and HDD/SSD storage standards the term format, as defined above, still has that original meaning. Format commands in the standards or the tool openSeaChest_Format are talking about the way in which the medium is layed out and how sectors are marked for use as originally done when you would format old disks for use. The only difference is interleave tables are no longer managed by software, it's a command to the disk's controller and it will go map out bad blocks, change sector locations and sizes, etc all on its own.
This is a short list of the commands that perform a format as defined in this page. This list may not be complete, but these commands all affect the internal formatting of the medium of a device.
- Format Unit (SCSI/SAS/FC)
- Format with Preset (SAS) or Mutate Ext (SATA)
- Format Tracks (ATA) (obsolete)
- Set Sector Configuration Ext (SATA) - Also called "Fast Format"
- NVM Format (NVMe)
- Remove Element and Truncate (SAS/SATA) - sometimes called "Depopulate"
- Remove Element and Modify Zones (SAS/SATA)
- Restore Elements and Rebuild (SAS/SATA)
- ZBD's that support Zone Domains and/or Zone Realms have other commands to change the medium's formatting for performance optimization of the zones and recording types they support.
The legacy sector size of all HDDs and SSDs has been 512 bytes in size.
As the industry went to larger sizes to optimize performance and storage density most drives shipped used a 512 byte logical sector size on a 4K physical sector. This is referred to as 512e or 512 emulated.
Over time and as operating system and software support improved to accept 4K sectors on hardware, 4KN or 4K native drives were made. These have a logical sector size of 4K and a physical sector size of 4K (4096).
In order to support various sector sizes, both the ATA and SCSI standards developed ways to report both sizes to the operating system as well as any alignment requirements that must be satisfied for optimal performance. All of these fields are reported in the output of openSeaChest_Format -d <handle> -i
If an OS and the filesystem are all supporting the alignment requirements reported by the device the risk of a performance penalty from RMW (Read-Modify-Write) is non-existent.
Windows Vista Service Pack 1 and later support aligning partitions to 4K boundaries. It does not matter if the drive is 512e or 4KN
Linux kernel 2.6.31 and later support aligning to 4K sector boundaries.
https://www.seagate.com/blog/advanced-format-4k-sector-hard-drives-master-ti/
If you are using one of these operating systems, they are already reporting the necessary alignment for reads and writes to the file systems and are fully capable of aligned reads and writes, meaning no performance penalty for 512e drives.
Another resource to check if you are ready for Advanced format can be found on IDEMA.org
SCSI/SAS/FC drives also can be found to support some sector sizes other than 512 or 4096. These sector sizes may also be found on some SATA or NVMe disks, but outside of enterprise applications and specific hardware RAID controllers, they are not often used.
This is a short list of sector sizes these drives:
- 520
- 524
- 528
- 4160
- 4192
- 4224
If you have purchased a drive with one of these sector sizes, it will likely not work or be recognized by most standard operating system configurations. Using openSeaChest_Format, you can attempt to reformat it to one of the common sizes:
SAS:
openSeaChest_Format -d <handle> --formatUnit 512 --poll --confirm this-will...
If your device is not SAS or SCSI, you will need to try one of the other format commands, however it is possible it is not changeable in some devices due to custom firmware restrictions or only changeable with vendor unique commands that are not known by openSeaChest.
These sector sizes allow for some extra space at the end of a sector for storing additional data such as a checksum which some enterprise RAID solutions support.
The T10 committee first defined Protection Information as a standardized method to pass CRCs and tags from the device all the way up the storage stack in a standardized way to replace the uncommon sector sizes above.
PI is also part of current NVMe standards for enterprise NVMe devices as well that is functionally equivalent to PI in T10 standards.
There are 4 PI types as of today:
| PI Type | Guard (CRC) | Application Tag | Reference Tag |
|---|---|---|---|
| 0 | N/A | N/A | N/A |
| 1 | Defined | Not Defined | Least significant 4 bytes of LBA |
| 2 | Defined | Not Defined | First LBA - expected value in command, +1 for each additional LBA. Uses 32B commands for SAS |
| 3 | Defined | Not Defined | Not defined by T10 standards |
A device is not required to support any PI modes other than 0 (transport layer protection only). A device may support any number of PI modes depending on its capabilities.
Logical block application tags are set by the host to identify data for a given tag. The device only modifies application tags when allowed in the control mode page.
NVMe devices may transmit the PI information as a separate buffer if they are formatted to support a separate Metadata pointer for each command.
Logical block application tags may follow the T10 standard if the Application Tag mode page is supported, otherwise they are not defined according to the T10 standards.
Each user data access command (Read/Write) had a field for RDPROTECT, WRPROTECT, or VRPROTECT that specified which fields the device must validate (Guard, Application Tag, Reference Tag). Validation of these fields can also be disabled depending on the value provided.
PI may not be compatible with fast-format. If switching sector size AND PI at the same time, this often requires a full device format. There is no way to tell from what a device reports in its capabilities to the host whether this is possible or not. It may or may not be described in a product manual.
If you attempt changing the sector size and formatting with PI at the same time with fast format and you receive a failure, then a full format is required to make this change.
The short answer: No.
The short version of the long answer: It depends.
The primary audience of fast format is customers that used to buy multiple drive models for different use cases (512e and 4KN). Since some use-cases require 512e and others require 4KN, it was simpler for vendors (like Seagate) and their customers to have a single model of drive that can be changed via software for the applications that require 4KN.
It is true that for 512e configurations that if your OS or applications have unaligned writes they would pay a penalty for read-modify-write behavior as the on media disk sectors are 4096 bytes. However as seen in the section above most systems are already capable of aligning writes for 512e devices.
The primary reason for staying with 512e is to preserve backwards compatibility for any software that may write smaller than 4096 bytes.
All modern Linux and Windows systems seem to be fully 4k aligned and use 4k or larger transfers. For these aligned cases there is no performance penalty running 512E vs 4K native.
In the past there was a format efficiency penalty for staying with sector sizes that had multiples of the physical sector size on disk. Today with the SFF-8447 changes for 8TB and greater there is a reduction in calculated sectors if PI is used on SAS and really no true efficiency gain for the customer in most cases.
The cases where 4KN provides an advantage:
- Hardware RAID optimized for 4KN drives.
- Data centers needing every single IOPS that have a hardware and software stack optimized for 4K sectors.
No. Before drive firmware and standards allowed for changing the sector size between 512e and 4KN vendors would sell different drive models for the sector size desired.
Even modern drives are not required to support this capability.
Some customer unique firmware may restrict the ability to perform a fast format due to their requirements to fit their original application. If you are buying a used drive you may need to be aware of this restriction, however these restrictions are not documented outside of the customer contracts made internally with a vendor.
After a fast format has completed, the drive may perform some additional background activity.
During this time the drive may not enter into low-power states as this activity is designed to make sure data integrity and reliability are kept after fast format.
The drive is ready for use even with this background activity. Each LBA that is written will reduce the time the background activity takes to run.
While some users may want to run a full overwrite before their data is written to avoid this background activity, this can take days on some capacities.
The benefit that fast-format provides is that instead of waiting for the drive to overwrite everything to zeroes again before you can use it from a full-length format, instead you can start writing you own data and the drive will perform the background tasks in the foreground with your own data instead. This is a significant time savings for writing to the drive with data rather than needing two separate writes: A zero pass and then the final user data.
Wait a second...HDD's are anything but high performance, how was it possible that they were faster than the CPU?
In the early days of computing CPUs could only access data using PIO and each transfer of a sector was followed by an interrupt that the CPU had to handle.
This was a lot of work on early CPUs and the speed at which early HDDs could spin and read data was faster than the CPU was able to process these interrupts.
To work around this, sector interleaves were used while formatting a HDD to better time the transfers at a more optimal speed that the CPU could match.
Here are some sample orders of different interleaves:
| Interleave | Sector order |
|---|---|
| 1:1 | 1,2,3,4,5,6,7,8,9 |
| 1:2 | 1,6,2,7,3,8,4,9,5 |
| 1:3 | 1,4,7,2,5,8,3,6,9 |
| 1:4 | 1,8,6,4,2,9,7,5,3 |
| 1:5 | 1,3,5,7,9,2,4,6,8 |
| 1:6 | 1,4,7,3,6,9,2,5,8 |
| 1:7 | 1,5,9,4,8,3,7,2,6 |
| 1:8 | 1,9,8,7,6,5,4,3,2 |
Software from these old days may have had the ability to test which interleave was optimal for your drive and CPU to make sure you got the most out of your hardware by doing some trial and error formatting and read tests.
Today, interleaves are a rarely remembered thing of the past for most and some people likely have never heard of them.
In the original SCSI standard the command Format Unit (which still exists today) supported a field to specify an interleave value as this was developed at the time when an interleave could still be valuable. An interleave table was not needed as the SCSI controller on the drive would figure it out, you simply passed a value in this field for the desired interleave. Official standards only defined a value of 0 or 1 for this field leaving all other options vendor specific. Later SCSI standards made this obsolete and this field was eventually retired. The byte originally used for the interleave is now used to specify which mode of Fast Format to use.