From owner-freebsd-current Tue Jul 28 08:20:38 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id IAA27703 for freebsd-current-outgoing; Tue, 28 Jul 1998 08:20:38 -0700 (PDT) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from pat.idi.ntnu.no (0@pat.idi.ntnu.no [129.241.103.5]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id IAA27698 for ; Tue, 28 Jul 1998 08:20:34 -0700 (PDT) (envelope-from Tor.Egge@fast.no) From: Tor.Egge@fast.no Received: from idi.ntnu.no (tegge@ikke.idi.ntnu.no [129.241.111.65]) by pat.idi.ntnu.no (8.8.8/8.8.8) with ESMTP id RAA12042; Tue, 28 Jul 1998 17:19:48 +0200 (MET DST) Message-Id: <199807281519.RAA12042@pat.idi.ntnu.no> To: karl@mcs.net Cc: current@FreeBSD.ORG Subject: Re: Serious Dump problems In-Reply-To: Your message of "Tue, 28 Jul 1998 07:35:23 -0500" References: <19980728073523.02311@mcs.net> X-Mailer: Mew version 1.70 on Emacs 19.34.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Tue, 28 Jul 1998 17:19:47 +0200 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Hi folks, > > I have an interesting one here... > > 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. > 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. > Any ideas on this one? Is there a more recent set of sources available > somewhere that might not display this problem? I suggest using a patch similar to this (barely tested) one in order to avoid the buffer overrun in restore. Index: tape.c =================================================================== RCS file: /home/ncvs/src/sbin/restore/tape.c,v retrieving revision 1.12 diff -u -r1.12 tape.c --- tape.c 1998/06/28 20:25:59 1.12 +++ tape.c 1998/07/28 13:45:29 @@ -104,6 +104,8 @@ static void xtrmapskip __P((char *, long)); static void xtrskip __P((char *, long)); +static int readmapflag; + /* * Set up an input source */ @@ -678,7 +680,7 @@ gettingfile++; loop: for (i = 0; i < spcl.c_count; i++) { - if (spcl.c_addr[i]) { + if (readmapflag || spcl.c_addr[i]) { readtape(&buf[curblk++][0]); if (curblk == fssize / TP_BSIZE) { (*fill)((char *)buf, (long)(size > TP_BSIZE ? @@ -697,7 +699,7 @@ } if ((size -= TP_BSIZE) <= 0) { for (i++; i < spcl.c_count; i++) - if (spcl.c_addr[i]) + if (readmapflag || spcl.c_addr[i]) readtape(junk); break; } @@ -1095,6 +1097,7 @@ qcvt.val[0] = i; buf->c_dinode.di_size = qcvt.qval; } + readmapflag = 0; switch (buf->c_type) { @@ -1105,8 +1108,11 @@ */ buf->c_inumber = 0; buf->c_dinode.di_size = buf->c_count * TP_BSIZE; - for (i = 0; i < buf->c_count; i++) - buf->c_addr[i]++; + if (buf->c_count > TP_NINDIR) + readmapflag = 1; + else + for (i = 0; i < buf->c_count; i++) + buf->c_addr[i]++; break; case TS_TAPE: @@ -1187,7 +1193,7 @@ blks = 0; if (header->c_type != TS_END) for (i = 0; i < header->c_count; i++) - if (header->c_addr[i] != 0) + if (readmapflag || header->c_addr[i] != 0) blks++; predict = blks; blksread = 0; > > Needless to say, unrestorable tapes are not my idea of a good time! I agree. - Tor Egge To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message