[TUHS] Mach for i386 / Mt Xinu or other
krewat at kilonet.net
Wed Feb 22 09:14:14 AEST 2017
Not to mention, DOS was pretty much single-threaded. It wasn't very
often that you had multiple threads writing files in different
locations. And when they did, a write was atomic. Update the block(s),
update the FAT. There was no preemption. Only when Windows (and it's
other multi-tasking brethren) came along was it possible that two
threads would be writing to different files. Even then, I'm willing to
bet that the entire "write block, update FAT" was atomic for the
DOS-based Windows. Of course, I'm only talking about the FAT file system
as it grew out of the first floppy-disk based PC's, and not NTFS nor the
NT-based Windows versions to come later.
However, it was possible to actually be in the middle of writing a block
(or sector) and cut the power and it wouldn't finish writing sector.
Leading to data or FAT corruption. If I remember correctly, when that
happened, it was best to manually pick through both FAT copies and see
which one was correct :)
The worst was overwriting an existing block, because the FAT wasn't
updated, and if the data wasn't completely written when the power cut,
well, say good bye to the disk sector it was on.
On 2/21/2017 4:49 PM, Noel Chiappa wrote:
> The duplicated FAT, and the way file sectors are linked using it, is I suppose
> a little more robust than other designs (e.g. the way early Unixes did it,
> with indirect blocks and free lists), but I think a lot of it must have been
> that DOS wrote stuff out quickly (as opposed to e.g. the delayed writes on
> early Unix FS's, etc). That probably appoximated the write-ordering of more
> designed-robust FS's.
More information about the TUHS