Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!husc6!linus!philabs!ttidca!retix!erik From: erik@retix.retix.COM (Erik Forsberg) Newsgroups: comp.unix.wizards,comp.unix.questions Subject: Re: How to recover from fsck "Cannot read block"? Message-ID: <202@retix.retix.COM> Date: Fri, 17-Jul-87 15:24:37 EDT Article-I.D.: retix.202 Posted: Fri Jul 17 15:24:37 1987 Date-Received: Sun, 19-Jul-87 06:49:40 EDT References: <412@acornrc.UUCP> <254@dgis.UUCP> <415@acornrc.UUCP> Reply-To: erik@retix.UUCP (Erik Forsberg) Organization: Retix, Santa Monica CA Lines: 24 Keywords: disk, fsck, help! Xref: mnetor comp.unix.wizards:3305 comp.unix.questions:3245 In article <415@acornrc.UUCP> bob@acornrc.UUCP (Bob Weissman) writes: > >Yes, I should have been more specific. > Host: VAX 11/750 > OS: Unix 4.2bsd > Disk: Eagle > Controller: ? I dunno about these. (Emulex SC750) > Driver: ? (standard BSD 4.2 hp driver) > Partition: /dev/hp1h or hp0h or .. > I have seen this many times too. It seems to consistently happens when doing a full restore. newfs /dev/hp0h eagle followed by a restore -r of a full level 0 dump. Seems to me it must be a bug in the file system. The only method of recovering I could figure out was using ncheck followed by icheck to figure out first which inode contains the bad block number reference. The we can figure out which file it was. In my case it was always a directory (/sys/mdec). After that, clri the bad inode, run fsck to fix the damage, restore the lost directory and everything is fine. -- ---------------------------------------------------------------------------- Erik Forsberg, Retix, 2644 30th Street, Santa Monica CA 90405 (213) 399-2200 UUCP: {bradley,hao,litvax,trwrb,sdcrdcf,ucla-cs,ucsbcsl}!cepu!retix!erik