[TUHS] Re: Unix v7 icheck dup problem

["Ron Natalie" <ron@ronnatalie.com>]

You had adb?    They hadn’t even released that when we were fixing 
things up.    If we had a mountable disk that got too corrupt to fix 
using the tools, we usually wrote our own and fixed the disk (all our 
packs in those days were pretty much RK05s) from a running sytsem.

It was reqiured before you could come on the operations staff at my 
college to be able to be quizzed on just how the (then version 6) 
filesystem was layed out and what the possible corruptions were and how 
to fix them.

The original V6 filesystem was pretty ugly in that it wasn’t careful in 
even trying to do operations in the right order so as not to lead to 
hideous corruptions (duplicated blocks etc…).   One of our summer 
projects at the BRL when we were interning up there was that one of us 
(not me) was to write an automatic disk fixer (I had a different 
project).   Bob never got too far with that.

Clri was especially problematic as a tool.   If you wanted to zap a node 
that was a 0..0 (i.e., with a zero reference count AND not in any 
directory referneces), it would irreverably write zeros over all of it.  
   We changed it to “clam” which only zonked the mode bits which if you 
did it to the wrong inode, you could usually get back to some working 
state.

Running icheck and dcheck were standard on reboots.   ncheck was pretty 
darned slow and we used it mostly for hunting down file names for things 
we knew were corrupted and relinking chunks of the filesystem that got 
detached from the root.

The world changed when we got better file system code and fsck.