News for hackers. Stuff that matters.
Re:Discovering Hard Disk Physical Geometry Through Microbenc... by userbinator on Monday February 19, 2024 @10:14PM (#39437645)
One of the more surprising facts revealed in this article is that modern HDDs don't go through the traditional CHS order with increasing LBAs, and the number of sectors per track can vary even between two sides of the same platter at the same radial distance. I suspect a lot of this information is kept secret by HDD manufacturers, and known only to them and those working in data recovery (if a drive has one dead head, or media damage on one surface, traditional CHS order vs. the others would show very different results in which portions remain readable.)
Re:Discovering Hard Disk Physical Geometry Through Microbenc... by nubinetwork on Tuesday February 20, 2024 @12:30AM (#39438345)
> and the number of sectors per track can vary even between two sides of the same platter at the same radial distance

Wouldn't that cause all sorts of issues with SMR drives?

Re:Discovering Hard Disk Physical Geometry Through Microbenc... by magicalhippo on Tuesday February 20, 2024 @05:29AM (#39439677)
The point with SMR is to overlap tracks like roof shingles, since the read heads can read a narrower track than the write heads can write.

In addition, the heads have multiple levels of independent actuation beyond the shared arm itself[1][2].

So as long as the tracks themselves are fairly consistent, I don't see why the number of sectors per track has to be equal.

[1]: https://pcper.com/2009/09/wd-unleashes-nested-actuator-and-a...

[2]: https://blog.westerndigital.com/hdd-magic-20tb-18tb/

Re:Discovering Hard Disk Physical Geometry Through Microbenc... by jorticka on Tuesday February 20, 2024 @01:40AM (#39438614)
It would be easy for competition to reverse engineer the physical layout.

I think it's "secret" because nobody really cares.

Do you care for example how the CPU maps the linear memory space across physical RAM sticks and chips? I recently discovered that there multiple alternatives and BIOS settings which give you some control over this.

Re:Discovering Hard Disk Physical Geometry Through Microbenc... by HPsquared on Tuesday February 20, 2024 @05:21AM (#39439630)
Dual channel is a thing, I suppose. Probably similar for hard drives: multiple heads, there might be some micro-trickery to align things just right.
Re:Discovering Hard Disk Physical Geometry Through Microbenc... by jorticka on Tuesday February 20, 2024 @09:06AM (#39441425)
I wasn't talking about dual channel, but something else. There are a number of ways to map linear memory space to multiple individual memory chips.
Re:Discovering Hard Disk Physical Geometry Through Microbenc... by ipython on Tuesday February 20, 2024 @03:17PM (#39446342)
People absolutely care!

You can't cheat physics, so at today's CPU speeds, spinning disk HDDs more closely resemble tape drives than not. You have to pay a significant performance price when moving the read head across the disk surface, moreso when you have to wait an entire rotation for the correct sector to fly under the read head.

Re:Discovering Hard Disk Physical Geometry Through Microbenc... by londons_explore on Tuesday February 20, 2024 @06:56AM (#39440218)
If I were designing drives, I would be considering the platter and all the mechanicals to be noisy, bendy, sticky, shaky, fade-y, and all the things you wished your mechanical parts weren't. Every part of the disk has different amounts of noise, shakiness, etc, since the manufacturing process isn't consistent.

Yet you want to store as much good data on the whole disk as possible, and need to be able to retrieve smallish chunks of the data back in the typical case quickish.

In turn, that constrains how you group data, and how you allocate ECC bits. As a seller of disks, it's probably how you decide if you should stick a 3TB, 4TB or 5TB sticker on the box too.

The end result will be an algorithm that, based on factory calibration and recent measurements decides how to map data to physical areas of the disk. One head giving a weaker signal lately? Well we're gonna assign fewer data bits there.

And when reading data back there are also decisions to be made. For example, when we read a bunch of data but the ECC recovery fails due to too much noise, should we re-read the same data and combine the reads to get more signal and less noise? Should we shake the head a little and see if we can re-read and get better alignment next time? Should we go and read a few tens of megabytes of other data and see if we can recover the data from a higher hierarchical level ECC/erasure coding scheme?