Re: write alignment matters?

[David Holland <dholland-tech%netbsd.org@localhost>]

On Sat, Jun 25, 2011 at 09:29:57PM +0700, Robert Elz wrote:
 > | At least for NetBSD, that's never been true.  The most glaring
 > | problem is that there's no protection against causing the same
 > | underlying disk blocks to be multiply cached by accessing the
 > | buffer cache with a different stride.  And no way to keep those
 > | multiple cachings coherent...
 > 
 > While there's no enforcement, the basic rule has always been "one
 > at a time", the same problem applies to raw devices if you have
 > multiple processes accessing the things without coordination.
 > While this one is worse, because of the caching delays and
 > unpredictable write order, it all just goes away if we prohibit
 > multiple access, doesn't it?

Only if closing one access and opening the next flushes all buffers,
which may not really be what you want. (Nor am I sure if it currently
happens.)

 > However, I don't expect that this is the only problem that exists.

Nope.

 > | There's also a problem that the buffer cache code wasn't ever designed to
 > | cope with removable devices, so bad things happen if you try to use the
 > | block device for something that isn't there (e.g. a floppy drive with no
 > | media in it) or that you eject before writeback has completed.
 > 
 > Oh you young'uns ...  [...]
 > 
 > Normal unix used rp06's, rk07's, rm03's, rm05's, etc - all
 > removable.  What didn't exist at the time (rather than removable
 > media) was the expectation that it should be possible to remove the
 > media without bothering to inform the OS that was about to happen,
 > and give the OS type to update the media properly before releasing
 > it.

That's not the issue. Or, that's an issue but it's not the important
one: if I eject half-written media and it's thereby corrupt it's my
own stupid fault.

The problem is much simpler: if the media is missing when you write to
the device (not necessarily because it's been ejected; possibly it was
never loaded) the writes succeed and then the buffer cache goes
berserk trying to flush data to nonexistent storage.

I've done this upon occasion (e.g., tried to dd a boot floppy image
but forgot to actually put the disk in) and it makes a nice mess;
basically you have to wait for it to individually retry and retry and
finally give up and error out on each sector of the floppy (during
which time the machine's more or less hung for other purposes) and
there's no way to stop it.

This is a bug, but it's not that easily fixed.

 > It took the invention of that paragon of OS's - DOS - to teach
 > the populace that simply pulling the device/media was an acceptable
 > operating procedure.

That's hardly fair. Until the Mac appeared in 1984 every small
computer that had a floppy drive had a floppy drive you could
open/eject arbitrarily, and none of them required explicit unmount.
This was true of at least some bigger systems as well; as I recall
RT-11 did not require explictly unmounting floppies before changing
them.

Furthermore, that Mac that appeared in 1984 still handled removable
media better than any Unix I've seen(*). You could eject disks that
had open files on the desktop; it would prompt you to reinsert them if
necessary, and managed to do this without getting mixed up or losing
track of the contents or forcing you to close things. AmigaDOS made
this work without software-only eject, too, so it's not like it's some
mystical Mac thing. And all that is getting near to thirty years ago
now; why can't we do it in Unix yet?

(*) Disclaimer: I haven't seen how late-model OS X handles USB sticks.

 > The one difference we have today, is that the controllers have moved
 > out to accompany the media, rather than remaining in the system, and we
 > haven't done a very good job (yet) of adapting to that change of
 > methodology - but that's just a SMOP (or not-so-S perhaps) not anything
 > that's a fundamental paradigm shift.

That's true but I don't think it's particularly relevant... the buffer
cache doesn't care much how data's read and written.

 > A device with no media isn't a problem, never was, accessing that is
 > simply an error, today as it always was.

Yes, or 2880*nretries errors...

-- 
David A. Holland
dholland%netbsd.org@localhost