From mboxrd@z Thu Jan 1 00:00:00 1970 From: clemc@ccc.com (Clem Cole) Date: Fri, 12 May 2017 11:18:53 -0400 Subject: [TUHS] The evolution of Unix facilities and architecture In-Reply-To: References: <20170512151256.B27CE18C09A@mercury.lcs.mit.edu> Message-ID: I should have said -- it was not hypothetical -- George implemented it and published the code and we all picked it up, On Fri, May 12, 2017 at 11:17 AM, Clem Cole wrote: > George Gobble of Purdue did the FS work to V7/4.1 to fix the FS corruption > issues. That was taken back by Kirk (wnj) and incorporated in 4.1A. It > may have been before USENIX was creating proceedings. I'll have to look > on my shelf at home or maybe ask George. > > Clem > > On Fri, May 12, 2017 at 11:12 AM, Noel Chiappa > wrote: > >> > From: "Ron Natalie" >> >> > Ordered writes go back to the original BSD fast file system, no? I >> seem >> > to recall that when we switched from our V6/V7 disks, the >> filesystem got >> > a lot more stable in crashes. >> >> I had a vague memory of reading about that, so I looked in the canonical >> FFS >> paper (McKusick et al, "A Fast File System for UNIX" [1984)]) but found no >> mention of it. >> >> I did find a paper about 'fsck' (McKusick, Kowalski, "Fsck: The UNIX File >> System Check Program") which talks (in Section 2.5. "Updates to the file >> system") about how "problem[s] with asynchronous inode updates can be >> avoided >> by doing all inode deallocations synchronously", but it's not clear if >> they're >> talking about something that was actually done, or just saying >> (hypothetically) that that's how one would fix it. >> >> Is is possible that the changes to the file system (e.g. the way free >> blocks >> were kept) made it more crash-proof? >> >> Noel >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: