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=-1.0 required=5.0 tests=MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 24468 invoked from network); 1 Mar 2023 15:09:17 -0000 Received: from minnie.tuhs.org (2600:3c01:e000:146::1) by inbox.vuxu.org with ESMTPUTF8; 1 Mar 2023 15:09:17 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id BE48743327; Thu, 2 Mar 2023 01:09:11 +1000 (AEST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by minnie.tuhs.org (Postfix) with ESMTPS id BD22843326 for ; Thu, 2 Mar 2023 01:09:06 +1000 (AEST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id AA4CD18C07B; Wed, 1 Mar 2023 10:09:05 -0500 (EST) To: tuhs@tuhs.org Message-Id: <20230301150905.AA4CD18C07B@mercury.lcs.mit.edu> Date: Wed, 1 Mar 2023 10:09:05 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Message-ID-Hash: JB5QF6CZPBVEUDP7H2LJTC5S6DO4NEUT X-Message-ID-Hash: JB5QF6CZPBVEUDP7H2LJTC5S6DO4NEUT X-MailFrom: jnc@mercury.lcs.mit.edu 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: jnc@mercury.lcs.mit.edu 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: > 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