From: krewat@kilonet.net (Arthur Krewat)
Subject: [TUHS] Mach for i386 / Mt Xinu or other
Date: Tue, 21 Feb 2017 18:14:14 -0500 [thread overview]
Message-ID: <b1e76fcc-00f6-cb39-acb5-f52836945b75@kilonet.net> (raw)
In-Reply-To: <20170221214913.1843B18C117@mercury.lcs.mit.edu>
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.
>
next prev parent reply other threads:[~2017-02-21 23:14 UTC|newest]
Thread overview: 88+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-21 21:49 Noel Chiappa
2017-02-21 23:10 ` Nick Downing
2017-02-21 23:14 ` Arthur Krewat [this message]
-- strict thread matches above, loose matches on Subject: below --
2017-02-26 18:33 Norman Wilson
2017-02-28 20:26 ` Dave Horsfall
2017-02-22 3:51 Rudi Blom
2017-02-22 1:22 Rudi Blom
2017-02-22 3:08 ` Cory Smelosky
2017-02-21 16:25 Noel Chiappa
2017-02-21 12:02 Noel Chiappa
2017-02-21 12:24 ` Steffen Nurpmeso
2017-02-21 12:57 ` Michael Kjörling
2017-02-21 15:02 ` Clem Cole
2017-02-22 1:50 ` Dan Cross
2017-02-22 2:25 ` Steve Nickolas
2017-02-22 3:11 ` Clem Cole
2017-02-22 4:07 ` Dan Cross
2017-02-22 4:17 ` Larry McVoy
2017-02-23 15:31 ` Nemo
2017-02-23 16:00 ` Clem Cole
2017-02-23 16:50 ` Nemo
2017-02-23 22:02 ` Dave Horsfall
2017-02-24 1:30 ` Clem Cole
2017-02-24 20:54 ` Dave Horsfall
2017-02-24 1:01 ` Jason Stevens
2017-02-22 10:16 ` jsteve
2017-02-21 15:15 ` Chet Ramey
2017-02-21 16:47 ` Larry McVoy
2017-02-21 18:58 ` Clem Cole
2017-02-21 19:21 ` Larry McVoy
2017-02-21 20:17 ` Clem Cole
2017-02-21 20:28 ` Steve Nickolas
2017-02-21 20:32 ` Larry McVoy
2017-02-21 22:58 ` Wesley Parish
2017-02-22 1:19 ` Clem Cole
2017-02-22 9:00 ` jsteve
2017-02-22 0:52 ` Andy Kosela
2017-02-22 1:04 ` ron minnich
2017-02-22 1:33 ` jason-tuhs
2017-02-22 3:18 ` Larry McVoy
2017-02-22 3:45 ` ron minnich
2017-02-22 4:06 ` Larry McVoy
2017-02-22 4:11 ` Larry McVoy
2017-02-21 4:16 Doug McIlroy
2017-02-20 6:38 Rudi Blom
2017-02-19 5:48 Jason Stevens
2017-02-17 16:55 Noel Chiappa
2017-02-17 20:04 ` Clem Cole
2017-02-17 15:47 Atindra Chaturvedi
2017-02-16 7:28 [TUHS] Mushi and Bagu Rudi Blom
2017-02-16 9:36 ` jsteve
2017-02-16 10:42 ` Nick Downing
2017-02-16 13:49 ` Rudi Blom
2017-02-17 11:30 ` [TUHS] Mach for i386 / Mt Xinu or other jsteve
2017-02-17 14:22 ` Clem Cole
2017-02-17 16:13 ` Chet Ramey
2017-02-17 14:29 ` Clem Cole
2017-02-17 17:23 ` Warner Losh
2017-02-18 22:25 ` Nemo
2017-02-19 6:20 ` jsteve
2017-02-19 7:01 ` Steve Nickolas
2017-02-19 13:46 ` Jason Stevens
2017-02-19 15:44 ` Larry McVoy
2017-02-20 18:14 ` Joerg Schilling
2017-02-20 22:24 ` Larry McVoy
2017-02-20 23:16 ` Steve Johnson
2017-02-20 23:18 ` Larry McVoy
2017-02-20 23:25 ` Steve Johnson
2017-02-20 23:20 ` Steve Nickolas
2017-02-21 0:12 ` Wesley Parish
2017-02-21 1:05 ` Steve Nickolas
2017-02-21 10:30 ` Joerg Schilling
2017-02-21 13:47 ` Random832
2017-02-21 15:18 ` Joerg Schilling
2017-02-21 15:54 ` Diomidis Spinellis
2017-02-21 16:38 ` Cory Smelosky
2017-02-21 16:48 ` Joerg Schilling
2017-02-21 16:32 ` Random832
2017-02-21 16:55 ` Joerg Schilling
2017-02-21 17:10 ` Dan Cross
2017-02-21 19:44 ` Joerg Schilling
2017-02-21 21:17 ` Dan Cross
2017-02-21 21:37 ` Larry McVoy
2017-02-22 8:57 ` jsteve
2017-02-22 9:56 ` Michael Kjörling
2017-02-22 10:26 ` jsteve
2017-02-22 10:29 ` Joerg Schilling
2017-02-19 21:19 ` Clem Cole
2017-02-20 0:29 ` Nick Downing
2017-02-20 1:58 ` Clem Cole
2017-02-20 1:29 ` Cory Smelosky
2017-02-19 22:59 ` Derek Fawcus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b1e76fcc-00f6-cb39-acb5-f52836945b75@kilonet.net \
--to=krewat@kilonet.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).