The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
* [TUHS] Re: Unix v7 icheck dup problem
@ 2023-03-01 21:29 Noel Chiappa
  2023-03-01 21:54 ` KenUnix
                   ` (3 more replies)
  0 siblings, 4 replies; 37+ messages in thread
From: Noel Chiappa @ 2023-03-01 21:29 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > I'm not sure if 'fsck' would fix these

Turns out it was called 'fcheck' when we had it.

    > I have a V6 one

I'd already put it on my Web site, here:

  http://ana-3.lcs.mit.edu/~jnc/tech/unix/s1/fcheck.c

if anyone wants it.


    > From: "Ron Natalie"

    > You had adb?

Yeah, MIT had a lot of stuff that 'fell off the back of a truck' (including
things like the circuit design tools, etc). Well, having an undergrad who was
in the famous Boy Scout troop at Bell helped... :-)


    > From: KenUnix <ken.unix.guy@gmail.com>

    > What I finally did was restore the ".disk" files from a previous backup

You may sit with Arlo Guthrie on the 'Windows user' bench. :-)


    > From: "Theodore Ts'o"

    > some have argued that if someone doesn't do backups of their research
    > data, maybe they don't *deserve* to get their Ph.D. :-)

'Think of it as evolution in action.'

Although I like the old story about the person at their oral exam and
the Coke bottle in the window.

	Noel

^ permalink raw reply	[flat|nested] 37+ messages in thread
* [TUHS] Re: Unix v7 icheck dup problem
@ 2023-03-06  8:14 Noel Chiappa
  2023-03-06  8:58 ` Jonathan Gray
  0 siblings, 1 reply; 37+ messages in thread
From: Noel Chiappa @ 2023-03-06  8:14 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > I'll turn this into a 'Fixing damaged V5/V6 file systems' article on
    > the CHWiki.

Here'a a first crack at it:

  https://gunkies.org/wiki/Repairing_early_UNIX_file_systems

Any suggestions for improvements/additions will be gratefully received!


I've also been amusing myself trying to figure out who wrote:

  http://ana-3.lcs.mit.edu/~jnc/tech/unix/s1/fcheck.c

and how it got to MIT - which might give us a clue as to who wrote it. (It's
clearly a distant ancestor to 'fsck'.) The fact that we've lost Ted Kowalski
is really hindering, alas. Interestingly, Dale DeJager, head of the CB-UNIX
group, earlier remembered Hal Pierson working on a file system checker early
on:

  "Hal also implemented the first file system check routine that was written
  in C. It replaced an .. assembler version from research"

but it's not clear if the thing Hal wrote, mentioned there, has any
relationship with the 'check' of V5:

  https://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/source/s1/check.c

Maybe one of the Labs old-timers here remembers where the V5 thing came from?
(I.e. did Ken or Dennis write it, or did it come from Columbus?) If you do, it
would be a big help!

   Noel

^ permalink raw reply	[flat|nested] 37+ messages in thread
* [TUHS] Re: Unix v7 icheck dup problem
@ 2023-03-04 14:41 Noel Chiappa
  2023-03-04 14:49 ` KenUnix
  0 siblings, 1 reply; 37+ messages in thread
From: Noel Chiappa @ 2023-03-04 14:41 UTC (permalink / raw)
  To: tuhs

    > From: Clem Cole wrote:

    > It had more colorful name originally - fsck (pronounced as fisk BTW)
    > was finished. I suspect the fcheck name was a USG idea. 

I dunno. I don't think we at MIT wold have gratuitously changed the name to
'fcheck'; I rather think that was its original name - and we pretty
definitely got it from CMU. 'fsck' was definitely descended from 'fcheck'
(below).


    > From: Jonathan Gray

    >> (are 'fsck' and 'fcheck' the same program?)

    > https://www.tuhs.org/cgi-bin/utree.pl?file=V7addenda/fsck

Having looked the the source to both, it's quite clear that 'fcheck' is a
distant ancestor of 'fsck' (see below for thoughts on the connection(s)). The
latter has been _very_ extensively modified, but there are still some traces
of 'fcheck' left.

A lot of the changes are to increase the portability, and also to come into
compliance with the latest 'C' (e.g. function prototypes); others are just to
get rid of oddities in the original coding style. E.g.:

  unsigned
        dsize,
        fmin,
        fmax
  ;

Perfectly legal C, but nobody uses that style.


    > From: Jonathan Gray

    > fcheck is from Hal Pierson at Bell according to
    > https://www.tuhs.org/Archive/Distributions/USDL/CB_Unix/readme.txt

Hmm. "the major features that were added to UNIX by CB/UNIX ... Hal Person
(or Pierson?) also rewrote the original check disk command into something
that was useful by someone other than researchers."

I poked around in CB/UNIX, and found 'check(1M)':

  https://www.tuhs.org/Archive/Distributions/USDL/CB_Unix/cbunix_man1_01.pdf

(dated November 1979). Alas, the source isn't there, but it's clearly in the
fheck/fsck family. (CB/UNIX also has chkold(1M), which looks to me like it's
'icheck'.)

So now we have a question about the ancestry of 'check' and 'fcheck' - is one
an ancestor of the other, and if so, which - or are they independent
creations? Without the source, it's hard to be definitive, bur from the
messages (as given in the manual), they do seem related.

Clem's message of 3 Mar, 14:35 seems to indicate the the original was from
CMU, authored by Ted Kowalski; he also:

  https://wiki.tuhs.org/doku.php?id=anecdotes:clem_cole_student

says "Ted Kowalski shows up for his OYOC year in the EE dept after his summer
at Bell Labs ... He also brought his cool (but unfinished) program he had
started to write originally at U Mich - fsck". So maybe the CB/UNIX 'check' is
descended from a version that Ted left behind at Bell Labs?

Is anyone in touch with Hal Pierson? He could surely clear up these questions.

	Noel

^ permalink raw reply	[flat|nested] 37+ messages in thread
* [TUHS] Re: Unix v7 icheck dup problem
@ 2023-03-03 18:22 Noel Chiappa
  2023-03-03 19:25 ` Chet Ramey
                   ` (3 more replies)
  0 siblings, 4 replies; 37+ messages in thread
From: Noel Chiappa @ 2023-03-03 18:22 UTC (permalink / raw)
  To: tuhs

    > From: KenUnix

    > So is it safe to say there is no fsck or similar for v7?

There was a version of 'fcheck' (are 'fsck' and 'fcheck' the same program?)
for V7, but I don't know if it's available. It would be really easy to
convert the 'fcheck.c' that I put up to a V7 version; the V6 and V7 file
systems are almost identical, except for the block size, I think.


    > From: Dan Cross

    > I believe you posted a link to end(3) here back in 2018

Yes, but that does't talk about '_end' not being defined if there
are missing externals, either! All it says is:

  "Values are given to these symbols by the link editor 'ld' when, and only
  when, they are referred to but not defined in the set of programs loaded."

Now that I think about it, I have this vague memory we had to look at the
source for 'ld.c' to verify what was going on!


    > From: Jonathan Gray

    > That is close, but slightly different to the PWB fcheck.c

Interesting. I wonder how 'fcheck' made it from CMU to Bell? Clem and I
discussed how it made it from CMU to MIT, and we think it was via Wayne
Gramlich, who'd been an undergrad at CMU, and then went to grad school at MIT.

I'm pretty sure the reason we liked it was not any auto-repair capabilities,
but ISTR it was somewhat faster than icheck/dcheck. (Interesting that they were
separate programs in V6; V5 seems to have only had check:

  http://squoze.net/UNIX/v5man/man8/check
  https://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/source/s1/check.c

which contained the functionality of both. I wonder why they were split?
Space?)


    > From: Rich Salz

    > But the amazing point was it worked regardless of bit order.

I forgot to mention thast, but yes, its input was the number in bit-serial
form. I suspect there's a connection between the property he mentioned, and
the fact that the grad student could design something which would work with
binary numbers fed in from either end, but I can't bring myself to devote the
brain cells to figure it out.


    > From: John Cowan

    > I didn't know that one was done at MIT.

Yes; see:

  https://www.hactrn.net/sra/alice/alice.intro

There's a really funny story at the end of that about the real Ann Marie
Finn. In Rob's version, she took the role of KAREN in the earlier one. That
would be Karen Prendergast, Patrick Winston's admin; why we used her I don't
know, since I didn't really know her, but I guess she had a reputation as a bit of
a 'tough cookie'.

    >> I think that the person fails their oral. I have no idea if it's a
    >> true story.

    > That's vicious.

Hey, this _is_ the school that used to tell incoming freshpeople, at the
welcoming picnic 'look at the person to your left, and to your right; at
graduation, one of you won't be here'. I don't remeber if they said the same
thing at mine, or if the story had just been passed down from class to class.

	Noel

^ permalink raw reply	[flat|nested] 37+ messages in thread
* [TUHS] Re: Unix v7 icheck dup problem
@ 2023-03-02  1:59 Noel Chiappa
  2023-03-02  2:11 ` Dan Cross
  0 siblings, 1 reply; 37+ messages in thread
From: Noel Chiappa @ 2023-03-02  1:59 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    >> _end

    > They are all in the V6 library.

Oops, not _end. In the V6 linker, "_end" is not defined if there are still
undefined symbols at the end of the linking run.

I remember finding this in some obscure place in the V6 documents; it's not
in 'ld(I)'. Anyone remember where it's discussed?

	Noel

^ permalink raw reply	[flat|nested] 37+ messages in thread
* [TUHS] Re: Unix v7 icheck dup problem
@ 2023-03-02  1:36 Noel Chiappa
  2023-03-02  1:56 ` John Cowan
  2023-03-02  2:12 ` Bakul Shah
  0 siblings, 2 replies; 37+ messages in thread
From: Noel Chiappa @ 2023-03-02  1:36 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > From: KenUnix

    > things are missing:

    > Undefined:
    > _setexit
    > _reset
    > _seek
    > _alloc
    > _end

    > Yes, I am trying to compile it on Unix v7.

Well, there's your answer. They are all in the V6 library. Here's
the source for setexit/reset:

  https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/s5/reset.s

You do realize that if you got it compiled under V7 and ran it, it would
trash the disk, right? (The V6 and V7 filesystems are different; very
similar, but block nubers are 16 bits on V6, ans 32 bits on V7.)

    > Is there a makefile?

No. No 'make' in V6. Which is why you find those 'run' shell files:

  https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/source/s4/run

everywhere.


    > From: John Cowan

    > It was an update/rewrite of the MIT version.

Which one? There were two: "MIT's AI Lab", by CSTACY, Alan Wecsler, and me;
which Rob Austein re-wrote into "Alice's PDP-10". I thought the original was
centered around ITS, but my memory was poor (hey, it has been ~40 years :-),
it seems to sort of be about LISP Machines. Rob's version was about TWENEX
(yech). The original was written in 926, MOON's office; I can't believe he
put up with me hanging out there!

    >> Although I like the old story about the person at their oral exam and
    >> the Coke bottle in the window.

    > Details?

So they're giving someone an oral exam. They can't make up their minds, or
something, and they ask the person to step out for a second. When the person
comes back in, they point to a Coke bottle sitting on a window-sill in the
sunlight, and ask them to examine it. The person notices that it's warm on
one side - the side facing the window. 'Why that side?', they ask. So the
person goes into a long explanation about how the curved glass must have
focused the light, yadda-yadda. WRONG! They turned it around while the
person was out of the room. I think that the person fails their oral. I
have no idea if it's a true story.

Steve Ward told another oral story which I'm pretty sure _is_ true, though.
They ask the candidate to design a state machine (or digital logic, I forget
which) which can tell if a number is divisible by three (I think I have the
details correct, but I'm not absolutely certain). So they describe one - and
then point out that you can feed the number in from either end (most or least
significant end first) - and proves that it will work either way! The
committee was blown away.

	Noel

^ permalink raw reply	[flat|nested] 37+ messages in thread
* [TUHS] Re: Unix v7 icheck dup problem
@ 2023-03-01 15:09 Noel Chiappa
  2023-03-01 16:18 ` Ron Natalie
                   ` (2 more replies)
  0 siblings, 3 replies; 37+ messages in thread
From: Noel Chiappa @ 2023-03-01 15:09 UTC (permalink / raw)
  To: tuhs; +Cc: jnc

    > I am having a problem clearing a dup inode.

V6 had almost no tools for automagically fixing file system corruption.
To do it, you need to i) understand how the FS works (see:

  https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/man/man5/fs.5

but it's pretty simple); ii) understand what the few tools (dcheck; icheck;
clri) do; iii) dive in.

I recall I used to use 'adb' a lot, to manually patch things when there was a
problem, so you'll want to study up on the 'db' syntax (no 'adb' in vanilla
V6, but for this, they are basically equivalent):

 https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/man/man1/db.1

You'll have to use the non-raw version of the device (the raw version can only
read/write complete blocks), and then judiciously use 'sync' to flush the
updated blocks out to the 'physical' disk. (There are some corner cases where
data is stored elsewhere, such as when one is patching the inode of an open
file, but I'm going to ignore them.)


    > # icheck -s /dev/rp0

'icheck -s' only rebuilds the free list; it doesn't help with any other error
(e.g. a block being assigned to two different files).

    > 4244 dup; inode=323

Which is probably what is happening here. 'icheck':

  https://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/man/man8/icheck.8

is not telling you what _else_ is using that block, because it has already
forgotten that by the time it discovers this second claimant (it only keeps a
bit array of 'used' blocks).

    > # icheck -b 323 /dev/rp0

Err, you wanted to say 'icheck -b 4244' to find out who else was using block
4244.


I'm not sure if 'fsck' would fix these; I have a V6 one, if anyone wants it.

The 'easy' way to fix this is i) copy the second file to somewhere else, ii)
delete the original, iii) re-build the free list (because the duplicate block
will now be in both the first file, and the free list), iv) examine both files,
and see which one has the smashed contents.

I'll turn this into a 'Fixing damaged V5/V6 file systems' article on the
CHWiki.

	   Noel


^ permalink raw reply	[flat|nested] 37+ messages in thread

end of thread, other threads:[~2023-03-07  2:05 UTC | newest]

Thread overview: 37+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-03-01 21:29 [TUHS] Re: Unix v7 icheck dup problem Noel Chiappa
2023-03-01 21:54 ` KenUnix
2023-03-01 21:55 ` John Cowan
2023-03-01 22:15 ` Jon Forrest
2023-03-02  4:16 ` Jonathan Gray
  -- strict thread matches above, loose matches on Subject: below --
2023-03-06  8:14 Noel Chiappa
2023-03-06  8:58 ` Jonathan Gray
2023-03-07  2:05   ` Kenneth Goodwin
2023-03-04 14:41 Noel Chiappa
2023-03-04 14:49 ` KenUnix
2023-03-03 18:22 Noel Chiappa
2023-03-03 19:25 ` Chet Ramey
2023-03-03 21:26   ` John Cowan
2023-03-04  0:23     ` Chet Ramey
2023-03-03 19:35 ` Clem Cole
2023-03-04  2:45   ` Jonathan Gray
2023-03-03 23:00 ` Jonathan Gray
2023-03-04  9:07 ` Jonathan Gray
2023-03-04 11:19   ` KenUnix
2023-03-02  1:59 Noel Chiappa
2023-03-02  2:11 ` Dan Cross
2023-03-02  1:36 Noel Chiappa
2023-03-02  1:56 ` John Cowan
2023-03-02  6:41   ` Lars Brinkhoff
2023-03-02  2:12 ` Bakul Shah
2023-03-02  2:46   ` Rich Salz
2023-03-01 15:09 Noel Chiappa
2023-03-01 16:18 ` Ron Natalie
2023-03-01 16:45   ` KenUnix
2023-03-01 16:57 ` Theodore Ts'o
2023-03-01 20:52 ` Dave Horsfall
2023-03-02  1:46   ` Jonathan Gray
2023-03-02  3:05     ` Dave Horsfall
2023-03-02  7:56       ` John Cowan
2023-03-02  8:53         ` Steve Nickolas
2023-03-02  8:01       ` Jonathan Gray
2023-03-02  7:34   ` arnold

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