[TUHS] Mach for i386 / Mt Xinu or other

[Arthur Krewat]

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.
>