Looks like that fast format option simply invalidates all the data. Any block not written to first, returns:
“unspecified logical block data” and complete without error
However, if the intent is to wipe the data, drives with secure erase might use that instead. Maybe not as fast, but more “secure”.
Of course, there are 2 main reasons to low level format a drive:
Change the block size from something other than 512 or 4096, to 512 or 4096. Most commonly used to make hardware RAID drives work as standard drives, like with ZFS. This MUST take forever, (well, a really long time).
“Fix” a drive that has too many failed blocks.
In the bad old days, I routinely formatted a SCSI drive that had read errors to refresh the low level format. If that did not work, then replace the drive.
I guess today it would be possible to “fix” a SATA or SAS drive with too many bad blocks, by low level formatting. And, if it still had too many bad blocks, perhaps reducing the size by 1GB. That would both restore spares and cover existing bad blocks. But, I don’t know if this is possible.
It occurs to me that most people don’t know about HDD sector headers and trailers, and those could be the ones to fail during a bad block incident. And why a low level format could “fix” the problem.
The way HDDs work, is to have this for each sector:
Sector header, written once during low level format
Tiny buffer space, (for head to switch from read to write, if writing)
Sector data
Sector ECC data
Tiny buffer space, (for head to switch off writing, if writing)
Sector trailer, written once during low level format
What happens during an actual write, is the HDD controller reads the appropriate disk head, awaiting until the sector header comes around. Then immediately after, writes the sector data and associated ECC data.
Over time, the sector header or trailer can become demagnetized due to being read all the time. And not being refreshed ever. Thus, on a read, the HDD controller may not be able to find the sector header, causing the data to be lost.
It is possible that current HDDs have changed the low level format, to write the sector header as part of the sector. Thus, writing any sector after the trailer of the prior sector. That would make more sense today, and reduce the overhead slightly.
Looking at the list of items for each sector, you can see why a 4KB sector is more efficient than a 512 byte sector. There is reduced overhead for sector headers, buffer spaces, trailer, and combined ECC data.
Gee, responses went into the Twilight Zone real fast…
I guess old farts can go off on a tangent real quick, (which I guess includes me, since I remember where I was during the first moon landing. Don’t get me started on but “NASA fakes the moon landings!”)
