26 May
2020
26 May
'20
1:06 p.m.
Fred writes:
..."MS-DOS 3.3 did not even come with a
disk cache."
and discusses problems with SMARTDRV (in MS DOS 4.01 and later).
I'm not sure if it was technically a form of caching, but the AmigaDOS
delayed floppy write (well before MS-DOS cache) caused enormous problems
for Amiga users. (It may well have contributed significantly to the lack
of market success.)
Basic problem: you save something to a floppy, and pull it out. You now
have a corrupted floppy. You needed to wait a few seconds for the OS to
decide "well, looks like I better flush the last few dirty sectors out to
that floppy".
(I contend it was a form of write caching, designed to speed writing to
floppies where writing tended to occur in nearby places.)
Stan
26 May
26 May
1:31 p.m.
On 2020-05-26 22:06, Stan Sieler via cctalk wrote:
Fred writes:
..."MS-DOS 3.3 did not even come with a
disk cache."
and discusses problems with SMARTDRV (in MS DOS 4.01 and later).
I'm not sure if it was technically a form of caching, but the AmigaDOS
delayed floppy write (well before MS-DOS cache) caused enormous problems
for Amiga users. (It may well have contributed significantly to the lack
of market success.)
Basic problem: you save something to a floppy, and pull it out. You now
have a corrupted floppy. You needed to wait a few seconds for the OS to
decide "well, looks like I better flush the last few dirty sectors out to
that floppy".
(I contend it was a form of write caching, designed to speed writing to
floppies where writing tended to occur in nearby places.)
They probably would just have to implement a "sync" command, and tell
people to use use it before ejecting a disk...
regards,
chris
5:04 p.m.
> Fred
> ... discusses problems with SMARTDRV (in MS DOS 4.01 and later).
On Tue, 26 May 2020, Christian Groessler via cctalk wrote:
> I'm not sure if it was technically a form of
caching, but the AmigaDOS
> delayed floppy write (well before MS-DOS cache) caused enormous problems
> for Amiga users. (It may well have contributed significantly to the lack
> of market success.)
> Basic problem: you save something to a floppy, and pull it out. You now
> have a corrupted floppy. You needed to wait a few seconds for the OS to
> decide "well, looks like I better flush the last few dirty sectors out to
> that floppy".
>
> (I contend it was a form of write caching, designed to speed writing to
> floppies where writing tended to occur in nearby places.)
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
They probably would just have to implement a
"sync" command, and tell people
to use use it before ejecting a disk...
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)
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.
27 May
27 May
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?
11:12 a.m.
On Wed, 27 May 2020, Peter Corlett via cctalk wrote:
I would be most intrigued to see what a hardware lock
and soft-eject for a USB
key would look like.
Eject would require fairly precise fit for a solenoid follower around the
perimeter.
Are the square holes in the USB-A top and bottom side standardized?
Are they strong enough to discourage ham-fisted users? (needs to also
ba a flashing light surrounding the port!)
Would red/green lights be enough to help mitigate the problem?
Win7 does sometimes erroneously report a device in use when all
application programs that accessed it have been closed. I am unaware of
how to query "WHICH program claims to still be using it?"
But the memory leaks and a few other problems are enough that WIN7 can
benefit from periodic restarts. It, at least MY copies, are definitely
NOT a permanently ON OS.
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.
A joke operating system doesn't provide much CHOICE of which filesystems
to use.
And it dates back decades, even to "advice" columns in magazines
recommending to turn VERIFY off in DOS.
(NOTE: for those unfamiliar: "VERIFY" (both DOS and Int13h) was not a read
after write compare of content; it merely confirmed that each sector that
was written was readable.)
[0] For anybody who values throughput over durability,
may I recommend
/dev/null for the ultimate in performance?
26 May
26 May
3:59 p.m.
On Tue, 26 May 2020, Stan Sieler via cctalk wrote:
Fred writes:
..."MS-DOS 3.3 did not even come with a
disk cache."
I definitely never said THAT.
and discusses problems with SMARTDRV (in MS DOS 4.01
and later).
Yes, THAT I said, but in terms of Win3.10 installing SMARTDRV, rather
than
DOS 4.01
I'm not sure if it was technically a form of caching, but the AmigaDOS
delayed floppy write (well before MS-DOS cache) caused enormous problems
for Amiga users. (It may well have contributed significantly to the lack
of market success.)
Basic problem: you save something to a floppy, and pull it out. You now
have a corrupted floppy. You needed to wait a few seconds for the OS to
decide "well, looks like I better flush the last few dirty sectors out to
that floppy".
(I contend it was a form of write caching, designed to speed writing to
floppies where writing tended to occur in nearby places.)
Yes, I would agree with calling it that, although different reasons why it
was done.
1440
days inactive
1441
days old
5 comments
4 participants
participants (4)
-
abuse＠cabal.org.uk -
chris＠groessler.org -
cisin＠xenosoft.com -
sieler＠allegro.com