Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 13 submissions in the queue.
posted by Fnord666 on Wednesday September 25 2019, @10:02AM   Printer-friendly
from the MS-what? dept.

Submitted via IRC for Bytram

How did MS-DOS decide that two seconds was the amount of time to keep the floppy disk cache valid?

MS-DOS 2.0 contained a disk read cache, but not a disk write cache. Disk read caches are important because they avoid having to re-read data from the disk. And you can invalidate the read cache when the volume is unmounted.

But wait, you don't unmount floppy drives. You just take them out.

IBM PC floppy disk drives of this era did not have lockable doors. You could open the drive door and yank the floppy disk at any time. The specification had provisions for reporting whether the floppy drive door was open, but IBM didn't implement that part of the specification because it saved them a NAND gate. Hardware vendors will do anything to save a penny.

[...] Mark Zbikowski led the MS-DOS 2.0 project, and he sat down with a stopwatch while Aaron Reynolds and Chris Peters tried to swap floppy disks on an IBM PC as fast as they could.

They couldn't do it under two seconds.

So the MS-DOS cache validity was set to two seconds. If two disk accesses occurred within two seconds of each other, the second one would assume that the cached values were still good.

I don't know if the modern two-second cache flush policy is a direct descendant of this original office competition, but I like to think there's some connection.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by RS3 on Thursday September 26 2019, @03:01AM

    by RS3 (6367) on Thursday September 26 2019, @03:01AM (#898916)

    Those are good possibilities. I was thinking of a higher-level of abstraction where the USB stick acts like a simple Flash drive, but in fact virtualizes the block device, and internally stores however it wants to, but now I'm not sure why bother doing all of that... unless there was another mechanism (protocol) to move data to the stick.

    > I doubt manufacturers are going to provide a mechanism to allow you to manipulate the internal workings of their firmware.

    Sure, but maybe there's a market for something better, with a simple tool to let you do things like change the internal filesystem for some reason, so maybe someone will make something for such a market.

    AFAIK, most USB sticks / Flash storage are FAT32 formatted by default.

    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2