The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: jnc@mercury.lcs.mit.edu (Noel Chiappa)
To: tuhs@tuhs.org
Cc: jnc@mercury.lcs.mit.edu
Subject: [TUHS] Re: Unix v7 icheck dup problem
Date: Wed,  1 Mar 2023 10:09:05 -0500 (EST)	[thread overview]
Message-ID: <20230301150905.AA4CD18C07B@mercury.lcs.mit.edu> (raw)

    > 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


             reply	other threads:[~2023-03-01 15:09 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-01 15:09 Noel Chiappa [this message]
2023-03-01 16:18 ` Ron Natalie
2023-03-01 16:45   ` KenUnix
2023-03-01 16:57 ` Theodore Ts'o
2023-03-01 20:52 ` Dave Horsfall
2023-03-02  1:46   ` Jonathan Gray
2023-03-02  3:05     ` Dave Horsfall
2023-03-02  7:56       ` John Cowan
2023-03-02  8:53         ` Steve Nickolas
2023-03-02  8:01       ` Jonathan Gray
2023-03-02  7:34   ` arnold
2023-03-01 21:29 Noel Chiappa
2023-03-01 21:54 ` KenUnix
2023-03-01 21:55 ` John Cowan
2023-03-01 22:15 ` Jon Forrest
2023-03-02  4:16 ` Jonathan Gray
2023-03-02  1:36 Noel Chiappa
2023-03-02  1:56 ` John Cowan
2023-03-02  6:41   ` Lars Brinkhoff
2023-03-02  2:12 ` Bakul Shah
2023-03-02  2:46   ` Rich Salz
2023-03-02  1:59 Noel Chiappa
2023-03-02  2:11 ` Dan Cross
2023-03-03 18:22 Noel Chiappa
2023-03-03 19:25 ` Chet Ramey
2023-03-03 21:26   ` John Cowan
2023-03-04  0:23     ` Chet Ramey
2023-03-03 19:35 ` Clem Cole
2023-03-04  2:45   ` Jonathan Gray
2023-03-03 23:00 ` Jonathan Gray
2023-03-04  9:07 ` Jonathan Gray
2023-03-04 11:19   ` KenUnix
2023-03-04 14:41 Noel Chiappa
2023-03-04 14:49 ` KenUnix
2023-03-06  8:14 Noel Chiappa
2023-03-06  8:58 ` Jonathan Gray
2023-03-07  2:05   ` Kenneth Goodwin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230301150905.AA4CD18C07B@mercury.lcs.mit.edu \
    --to=jnc@mercury.lcs.mit.edu \
    --cc=tuhs@tuhs.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).