[TUHS] Unix v7 icheck dup problem

KenUnix ken.unix.guy at gmail.com
Thu Mar 2 02:45:37 AEST 2023


Thanks for all your suggestions.

What I finally did was restore the ".disk" files from a previous backup
'tar -xf ~/research-backups/backup-mu-0228.tar'
under Linux then restored my backup copies of files using 'tar x0
backup.tap' under Unix v7.

All is well now. Thanks
Ken


On Wed, Mar 1, 2023 at 11:19 AM Ron Natalie <ron at ronnatalie.com> wrote:

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

-- 
End of line
JOB TERMINATED
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tuhs.org/pipermail/tuhs/attachments/20230301/a3ebe2a7/attachment.htm>


More information about the TUHS mailing list