Re: Is Parallel Programming Hard, And, If So, What Can You Do About It?

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

On Mon, 12 May 2025 08:05:56 +0200, Terje Mathisen wrote:
>

Lawrence D'Oliveiro wrote:

>
One of my pet peeves is disk drives with memory caches in them. Why?
 

For reads it allows the disk to always read full sets of sectors, the
following blocks are likely to be needed soon anyway.

>
Leave that up to the OS I/O optimization algorithms. Because they know
things about the data that the drive doesn’t.

In this case the drive knows things that the OS does not: Consider
that the OS asked for sector N what happens when the arm finally has
settled enough to read from the track, and the first sector it sees is
sector N+10.  Now the drive could employ a work-to-rule attitude and
ignore all sectors until it finds sector N, and then send that over to
the OS.  The OS takes a little time and asks for N+1.  Unfortunately,
your work-to-rule HDD has already rotated a little way into sector
N+1, so it has to wait another rotation for N+1, and so on.  By
contrast, a read-caching HDD will read the whole track in one
rotation, and then deliver sector N and all the other sectors from
that track that the OS asks for out of the cache.

For writes, as long as the drive has enough energy (maybe in the form of
spinning inertia, or a hefty cap?) the always be able to save the buffer
cache to spinning rust, it can allow operations to complete immediately,
or as soon as the data has been transferred into the disk cache.

>
In other words, telling lies to the OS that the write has completed when
it hasn’t.

Not necessarily.  When you do command queuing and report the writes as
completed only when they actually have completed, you also need RAM on
the drive for storing all the queued writes and their data.

This kind of thing can really stuff up filesystem integrity
guarantees.

Which file system offers any useful integrity guarantees?  When I last
looked in the Linux docs, the only file system giving any integrity
guarantees at all was NILFS2.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
  Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>