From Newsgroup: comp.sys.raspberry-pi

On Mon, 11 Apr 2022 15:22:47 GMT, scott wrote:

Ahem A Rivet's Shot <steveo@eircom.net> wrote:

On Fri, 08 Apr 2022 15:05:11 +1200
nospam.Shaun.Buzza@f110.n229.z1.fidonet.org (Shaun Buzza) wrote:

For best performance, I would also ensure the swap partition was at
the *front* on a HDD; for a SSD (or SD card), it wouldn't matter.

Why ? Putting it dead centre of the tracks would seem to
minimise
average seek time to the swap area.

For spinning rust, data transfer rates are usually higher at the
beginning of the disk than at the end.

Agreed, but for even quite a small disk capacity (I'm thinking of the old
the 14", 20 surface, 3600rpm removable disks as used by mainframes and minicomputers until the early 1980s), when the relatively sluggish head movement speed made the difference in read speed between outer and inner tracks irrelevant.

These disks held around 60 Mchars/Mbytes and typically had 135mS random
access times, or around 7.5 accesses a second. They were pretty much the
norm on smaller manually operated mainframes and minis. Sequential read
wasn't a lot faster: IIRC there was no interleave and a disk revolution
was 16.6 mS at 3600 RPM, so you got around 60 reads a second: a whole 8
times faster than random access. In this era the disk controller was often several metres away from its drives and AFAIK, although it knew which cylinder[*] the heads were on it had no way to know which sector was under
the heads.

These numbers I gave are for an ICL 1903 running UDAS, which was typically used in unitasking mode, with programs either run manually by an operator
or sequentially a stack of job cards by the George 1 single streaming OS.

However, the 1903 could run George 3 if it had at least 32K of 24 bit
words of RAM, and G3 was a full multitasking OS and had an improved disk accessing system which tracked disk head position and direction of
movement and maintained two sorted queues of access requests: one was for accesses ahead of the heads and the other was for accesses behind the
heads. It worked by servicing requests from the 'ahead' queue until that
was empty and then switching direction. Even this simple strategy roughly doubled the disk access rate. The difference was obvious if you stood by
the drives, listened and watched: compared with the heads thrashing in and
out when accessing a random or indexed dataset under UDAS, the volley of clicks you heard as the heads floated gently in and out across the disk
under George 3 was obviously doing more work in less time.

I don't recall disks being much faster than that until controllers with built-in track buffering became commonly integrated into 5", 3.5" and 2.5" disks.

[*] back in the day we talked about 'cylinders' rather than 'tracks'
because, depending on capacity and manufacturer, a 14" removable disk had anywhere from 1 to 40 recording surfaces and could hold anywhere from 5 MB
to 1 GB.
--- Synchronet 3.20a-Linux NewsLink 1.114