12 May
2017
12 May
'17
3:12 p.m.
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
12 May
12 May
3:17 p.m.
New subject: The evolution of Unix facilities and architecture
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 <jnc(a)mercury.lcs.mit.edu>
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
3:18 p.m.
New subject: The evolution of Unix facilities and architecture
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 <clemc(a)ccc.com> 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 <jnc(a)mercury.lcs.mit.edu>
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
3:46 p.m.
New subject: The evolution of Unix facilities and architecture
I just did a small amount of hunting. The oldest printed USENIX Proceeding
seems to be 1983 [which was the one Rob gave 'cat -v considered harmful' -
although only the abstract is in it].
George did the ordered writes work earlier as I was still at Tektronix,
because I remember getting a tape from him a putting the changes into our
V7 system.
If we hunt around for a 'Purdue-EE' distribution circa '79-'81 we
should be
able to find it. BTW: as a piece of History for Diomidis on that same tape
is fix for one of the first '0-day' UNIX exploits I can remember. I'll
see
if I can find it and identify it for you. That would be a good piece of
history to call out.
The story is this ...
George was very upset when he found it. But this was during the time when
UNIX was fighting a bit for it's life in the press as not being a 'real'
OS. DEC and IBM making claims that it was a toy, *etc*. So most of the
the hacker community took it pretty seriously. It is funny, today we
would react in the opposite manner., But, there was a big 'hush-hush'
meeting at a Summer USENIX that was very exclusive to be invited too. We
were in a private conference room, the door was locked etc. I remember
that Dennis was there, Joy was there. Ron's old friend Mike must have been
in it. I think a couple of the Rand folks. Anyway - it was an issue with
profile(2) -- surprise, surprise. Pretty easy fix. We all took the code
back and promised to get patches out ASAP and not tell any one about it.
Clem
On Fri, May 12, 2017 at 11:18 AM, Clem Cole <clemc(a)ccc.com> wrote:
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 <clemc(a)ccc.com> 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 <jnc(a)mercury.lcs.mit.edu>
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
2541
days inactive
2541
days old
3 comments
2 participants
participants (2)
-
Clem Cole -
jnc＠mercury.lcs.mit.edu