From owner-freebsd-current Tue Jul 28 15:11:12 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id PAA29866 for freebsd-current-outgoing; Tue, 28 Jul 1998 15:11:12 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from smtp02.primenet.com (daemon@smtp02.primenet.com [206.165.6.132]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id PAA29744 for ; Tue, 28 Jul 1998 15:10:32 -0700 (PDT) (envelope-from tlambert@usr04.primenet.com) Received: (from daemon@localhost) by smtp02.primenet.com (8.8.8/8.8.8) id PAA18753; Tue, 28 Jul 1998 15:09:51 -0700 (MST) Received: from usr04.primenet.com(206.165.6.204) via SMTP by smtp02.primenet.com, id smtpd018651; Tue Jul 28 15:09:40 1998 Received: (from tlambert@localhost) by usr04.primenet.com (8.8.5/8.8.5) id PAA19411; Tue, 28 Jul 1998 15:09:34 -0700 (MST) From: Terry Lambert Message-Id: <199807282209.PAA19411@usr04.primenet.com> Subject: Re: Serious Dump problems To: Tor.Egge@fast.no Date: Tue, 28 Jul 1998 22:09:34 +0000 (GMT) Cc: karl@mcs.net, current@FreeBSD.ORG In-Reply-To: <199807281519.RAA12042@pat.idi.ntnu.no> from "Tor.Egge@fast.no" at Jul 28, 98 05:19:47 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > I have a dump tape which is intact, yet restore complains about "hole in > > map" and segv's when attempting to start up in interactive mode. > > Philip Inglesant gave a good description of this > problem on the -stable list. > > You probably had more than 4 million inodes on the file system. Thus > the bitmaps uses more than 512 KB(i.e. more than 512 tape blocks). > > Running dump/restore using a 51 GB partition (with 13 million inodes > gave the same problem for me. This is a very good catch. I looked at this problem when it was originally reported several months ago, and it seemed to me that the only way it could happen were if there actually were a hole in the map. The only thing I could conclude was that there was "something wrong with the data". > > It appears that dump and restore are VERY old, and nobody is maintaining > > them. Interestingly enough, a new dump of the same filesystem produces > > the same error, so I suspect a problem with dump where it is writing out a > > bad directory map. > > It is not sufficient to only change dump. The calculation of maxino > in restore depends upon the current behavior of dump, using a > value larger than 512 in the c_count field when the number of inodes > is larger than 4 million. > > Only a small change to restore is needed. Is it sufficient to change restore? Or is this patch going to result in part of the dumped data being inaccessable? Is a change to dump *also* necessary? Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message