Recently I've moved away from Arch Linux [It died after an update ;-) ] in favor of FreeBSD on my desktop. As in my habit, I've become interested into speeding up stuff

When reading "man tuning", I have found a following passage:

Quote:

When using bsdlabel(8) or sysinstall(8) to lay out your file systems on a
hard disk it is important to remember that hard drives can transfer data
much more quickly from outer tracks than they can from inner tracks.

On the other hand, I remember advice from an Arch wiki:

Quote:

The partition layout can influence the system's performance. Sectors at the beginning of the drive (closer to the center of the disk) are faster than those at the end.

So...

Who is right?

I'm pretty lame in physics... If anyone would be so nice to explain it for me in a trivial way, I'll be very grateful

Most hard drives obscure information like that, so the only real way to know is to test.

Gregory Smith's PostgreSQL 9.0 High Performance has a lot of information for "benchmarking" hard drives, and the data in the book tends to mirror what the Arch wiki says.

But, does that mean the hard drive actually "starts" on the outer tracks (which would be faster) and "ends" in the slower center tracks? You aren't given that privileged information by the hard drive vendor.

A fun obfuscation is that the "first" partition normally is on the outer-most of the drive.

If you slice a pizza into 6 slices, getting from slice 1 to 2 is "quicker" from closer to the center, since there the radius is less than at the outside nearer to the crust. This is how many people think of drives - this is what I'll call "a"

However, if you have equally-sized areas on the whole thing - meaning the outers are no larger than the inners - and the whole thing is spinning - then the outers are spinning faster than those on the inside (sitting on the outer edge of a carousel vs towards the center). This is what I'll call "b"

There's also more data available per cylinder without having to move heads on the outer tracks.

My wonderful paint example is attached....

My opinion: "man tuning" is correct, and while arch is correct about "Sectors at the beginning of the drive are faster than those at the end." (since the beginning of the drive is the outside of the drive) they should have left out the part about "(closer to the center of the disk)"

The geometry translation done by drive manufacturers has been mentioned already. But another factor has not: RPS miss is often a significant performance factor and due to translation you cannot predict it's impact, even when access patterns are predictable.

I'm going to try to describe RPS miss in more detail, since when it occurs it is outside your control on modern drives.

For this example I shall pick a SATA drive currently being marketed: somewhat at random, I chose the first "internal PC hard drive" for sale today at www.newegg.com: the "Seagate Barracuda 7200.14 ST3000DM001 3TB 7200 RPM 64MB Cache SATA 6.0Gb/s 3.5" Internal Hard Drive. Per Seagate, this drive has a sustained data rate on the outer diameter of 210 MB/s. The SATA bus transfers at a higher rate, of course, but 210 MB/s is the physical limit the drive has to read from or write to the platters. The average transfer rate for this drive is 156 MB/s.

The PDF spec sheet for the drive describes average seek times as 8.5 ms for reads and 9.5 ms for writes -- this is the time it takes to move the head assembly to the appropriate physical cylinder. If the heads have to move, this is the average time it takes to move the heads before reading or writing may occur. And note that any time the heads have to move again ... its another 8.5 or 9.5 ms on average to move the heads. 9ms for a read or a write, on average.

This is a 7200 RPM drive. The platters rotate in a complete circle every 8.33 milliseconds. (60 seconds / 7200 rotations). Once the heads have completed their seek to the appropriate cylinder, the platters must spin until the first sector to be read or written is underneath the appropriate head. This will average 4.16 ms ... the "latency" shown in the marketing literature.

Let's look at the drive transfer rate: maximum: 210 MB/s. Average (mid platter) 156 MB/s. I can estimate that the slowest (inner platter) transfer rate would be 102 MB/s. These are 4096 byte sectors - the fastest read/write of a single sector is 18.6 microseconds along the outer cylinder, and I estimate the slowest transfer is 38.3 microseconds.

However, this does not account for head movement (seek). Add seek and the difference between the inner and outer cylinders is negligible: 9018.6 microseconds vs 9038.3 microseconds on average to seek and read or write.

Now, add RPS Miss, or in modern terms, "latency": the average time spent waiting for the platters to spin to the appropriate sector under the heads. The new average for a read or write after a seek is 13178.6 microseconds for a sector on the outer edge, or 13198.3 microseconds on the inner edge.

You have no control over seeks or over latency (RPS Miss), as the physical mapping has nothing to do with the mapping of sectors reported to the OS by the drive. The drive manufacturers add caches and for sequential sector reads, at least, the electronics will usually attempt to read-ahead in order to pre-populate the cache with the next set of expected sectors.

You can't know if sector mapping as presented to your OS has anything to do with physical mapping. If you conduct performance tests of what appear to be inner and outer cylinders, you may see no appreciable differences, or any differences may be accounted for in the sequential or random nature of your I/O requests and how many cache hits the electroncs can provide based on the amount of read-ahead sectors.

J65nko just reminded me (from this post in another thread) that for 4096-byte sector disk drives that map to 512-byte sector devices (called "Advanced Format 512e" devices) there is additional latency on write operations that write 512-byte sectors, for a process called Read-Modify-Write ("RMW"):

Seek to the cylinder

Wait for the sector to rotate under the head

Read the 4096-byte sector into cache

Modify the 512-byte sub-sector in cache

Wait for the sector to rotate under the head

Write the 4096-byte sector.

The alignment issue J65nko refers to in his post is to when a sequential 512-byte write from the OS crosses the 4096-byte physical sector boundary, requiring a second RMW operation, and all the extended milliseconds that requires for RPS latency.