[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