27 May
2020
27 May
'20
4:23 a.m.
On Tue, May 26, 2020 at 05:04:10PM -0700, Fred Cisin via cctalk wrote:
[...]
also, the Amiga wrote track rather than sector at a
time, so a sector write
needed to be delayed until the track was ready to be written
And could therefore corrupt ten unrelated sectors from other files at the same
time. When it popped up "You MUST replace volume Empty in DF0:", it was not
messing about.
[...]
computer/OS control of disk eject and power is
what's needed to solve it.
Either hardware locks, or very thorough (difficult) eductaion of users. If
the user ASKS THE OS to eject the disk, then it can easily be delayed until
safe to do it. Similar with power shutdown (which users are now familiar
with)
There are SCSI commands for locking drives and performing eject and
contemporary operating systems do seem to use them. You'll mostly observe this
when using optical media because that's the only non-obsolete hardware left
which still supports them, and most of the time they're used for read-only
media anyway so it's somewhat moot.
I would be most intrigued to see what a hardware lock and soft-eject for a USB
key would look like.
In addition, the performance improvement that SMARTDRV
did of optimizing the
sequence of multiple writes out of sequence (all directory sectors, THEN all
disk sectors) was dangerous if there was an interruption (not necessarily
just user) before it was finished.
Fortunately, there now exist robust filesystems which ensure that partial
writes are not visible and that only the last few seconds of uncommitted data
still in the write queue is lost. Unfortunately, these tend not to be used much
because they're "slow"[0] and/or because it's on removable media
formatted with
a joke filesystem because of Windows.
[0] For anybody who values throughput over durability, may I recommend
/dev/null for the ultimate in performance?