From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 4133 invoked from network); 1 Mar 2023 16:46:08 -0000 Received: from minnie.tuhs.org (2600:3c01:e000:146::1) by inbox.vuxu.org with ESMTPUTF8; 1 Mar 2023 16:46:08 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 3B41243333; Thu, 2 Mar 2023 02:46:03 +1000 (AEST) Received: from mail-pj1-x1034.google.com (mail-pj1-x1034.google.com [IPv6:2607:f8b0:4864:20::1034]) by minnie.tuhs.org (Postfix) with ESMTPS id 7934B4332E for ; Thu, 2 Mar 2023 02:45:55 +1000 (AEST) Received: by mail-pj1-x1034.google.com with SMTP id bo22so2372556pjb.4 for ; Wed, 01 Mar 2023 08:45:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=fvfm0uYQvEVkmgBBjZXEP385aOSFtrJfEqKEo6YxUtc=; b=XGbTVQYBK+qiog8V0JSmF7mN0iS6iHsSGFCyLA2IB1BkEXJz212o2t6/5pwOURaOJC iUz+vOC+iAJF3JIYwGRtUoObOVWt1idCKxlT4ddDp5UMd4TysMZQntKVLxvKzPFrQ5cA 6c0e+PEwloxMYavxzWjxa7jHMGyehEeQXJZHRO9dpKFQ9Y6zd25Fh2COe8mnSCDR13qX 0PF4ihveQ1FzpliiTYbLJ48/Xo03OxwNDp27Yy6WKAgqCrOxeeprIDJcDJL6QMmZxdOM /9WBn3LQx7oA1zrfw0vSDPNC4tyaQZjbNKOsd2e4laccFiJF4Zc/ANPgeuArJm4jg5Qr sc6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=fvfm0uYQvEVkmgBBjZXEP385aOSFtrJfEqKEo6YxUtc=; b=nKo35tD6R2UXC0PATuCqo819AhKESbkn08n2XzynNsUiXU6puInLAtm/7XJI/nLZzy J67BmlwLryPMw/zEKu1GilyyQgjVkl/Inhg3fDNTKERrQqG+Mw0QoSD8pTejmtJRAhJj Z7fLyvr5l1Qpiyg7m1xS9u7RaLcFuv4TZG/Jbs2SYck8qQlZW+N49tIhN9VDDhqzEb1a p81IcqSn7Kd+zOKkv+lxKm45iFOZ0M9sL0xWaKfxQXtf++fs2mOdtl+KSZfeiSfO36cf 5aa1/1/sMeJSUfGTA8KqWuT02L5cgUqA9arkHz4ixFMToZn1sXSHLxccn0uG4CrAnaCr fXvQ== X-Gm-Message-State: AO0yUKV3mcr929VJQVkV3wWUkyLbnpN82SWC6h0AQfNhBVIP0wzhqDxo mPAqG6F6YNmvRUZdfERlo1LMoFshPqNni6fqCHnT3s6c X-Google-Smtp-Source: AK7set8b4i8NChKRZdnc9/Eoely0zuvHG3i6ICF/j384dbZ+M4ObAINRLrDsCW4A9pXY3eIaFWj/iQ2H0zWHa4ONToc= X-Received: by 2002:a17:902:cecf:b0:19c:df4e:f3c2 with SMTP id d15-20020a170902cecf00b0019cdf4ef3c2mr9505287plg.6.1677689154654; Wed, 01 Mar 2023 08:45:54 -0800 (PST) MIME-Version: 1.0 References: <20230301150905.AA4CD18C07B@mercury.lcs.mit.edu> In-Reply-To: From: KenUnix Date: Wed, 1 Mar 2023 11:45:37 -0500 Message-ID: To: Ron Natalie Content-Type: multipart/alternative; boundary="0000000000001b57ed05f5d97251" Message-ID-Hash: 7BU65KL7XZLE5UHQZRTELNYTUCZEXIOT X-Message-ID-Hash: 7BU65KL7XZLE5UHQZRTELNYTUCZEXIOT X-MailFrom: ken.unix.guy@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: Noel Chiappa , tuhs@tuhs.org X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: Unix v7 icheck dup problem List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --0000000000001b57ed05f5d97251 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFAM Ron Natalie wr= ote: > You had adb? They hadn=E2=80=99t even released that when we were fixin= g > 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=E2=80=99t care= ful in > even trying to do operations in the right order so as not to lead to > hideous corruptions (duplicated blocks etc=E2=80=A6). 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 =E2=80=9Cclam=E2=80=9D which only zonked the mode bit= s 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. > > --=20 End of line JOB TERMINATED --0000000000001b57ed05f5d97251 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for all your suggestions.

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

All is well now. = Thanks
Ken


On Wed, Mar 1, 2023 at 11:19=E2=80= =AFAM Ron Natalie <ron@ronnatalie.= com> wrote:
You had adb?=C2=A0 =C2=A0 They hadn=E2=80=99t even released that when we= were fixing
things up.=C2=A0 =C2=A0 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=E2=80=99t carefu= l in
even trying to do operations in the right order so as not to lead to
hideous corruptions (duplicated blocks etc=E2=80=A6).=C2=A0 =C2=A0One of ou= r 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).=C2=A0 =C2=A0Bob never got too far with that.

Clri was especially problematic as a tool.=C2=A0 =C2=A0If 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.=C2= =A0
=C2=A0 =C2=A0We changed it to =E2=80=9Cclam=E2=80=9D 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.=C2=A0 =C2=A0ncheck 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<= /div>


--0000000000001b57ed05f5d97251--