If the OS is scanning from one edge of the disk to the other, doing so from behind the Logical Block Addressing (LBA) abstraction, although it may aim to service requests in an elevator-like way, what guarantee do we have that the physical mapping correlates to what we see as the OS?
i.e. Could it be that servicing requests in logical order would end up seeking to random physical sectors, or do logical addresses still approximately reflect physical locations?
You are right, this could be a problem.
In older disks, the physical block number corresponds to the actual location of the block on the disk. So, that algorithm makes sense.
Newer disks do fancier stuff. They have firmware that might remap blocks around to different locations, so that the physical block number no longer corresponds to the actual location of the block on disk in all cases (two blocks with similar physical block number might be far apart in actuality). Because this can screw up OS scheduling algorithms, disk firmware generally tries to avoid this situation where possible, but it can happen.
It gets especially tricky with SSDs, which have very different performance properties than hard disks, but which must (for backwards compatibility) use an API originally designed for magnetic disks. So, modern SSD's do clever things to try to ensure that typical OS scheduling algorithms will still yield reasonable results, even though the physical block number doesn't necessarily correspond to the actual physical location of where the data is stored on the SSD.
