Date: Tue, 28 Jul 1998 11:00:43 -0500 From: Karl Denninger <karl@mcs.net> To: Tor.Egge@fast.no Cc: current@FreeBSD.ORG Subject: Re: Serious Dump problems Message-ID: <19980728110043.36780@mcs.net> In-Reply-To: <199807281519.RAA12042@pat.idi.ntnu.no>; from Tor.Egge@fast.no on Tue, Jul 28, 1998 at 05:19:47PM %2B0200 References: <19980728073523.02311@mcs.net> <199807281519.RAA12042@pat.idi.ntnu.no>
next in thread | previous in thread | raw e-mail | index | archive | help
This patch appears to fix restore. Can someone review and commmit this PLEASE? Thanks. -- -- Karl Denninger (karl@MCS.Net)| MCSNet - Serving Chicagoland and Wisconsin http://www.mcs.net/ | T1's from $600 monthly / All Lines K56Flex/DOV | NEW! Corporate ISDN Prices dropped by up to 50%! Voice: [+1 312 803-MCS1 x219]| EXCLUSIVE NEW FEATURE ON ALL PERSONAL ACCOUNTS Fax: [+1 312 803-4929] | *SPAMBLOCK* Technology now included at no cost On Tue, Jul 28, 1998 at 05:19:47PM +0200, Tor.Egge@fast.no wrote: > > 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 <philip@dircon.net> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980728110043.36780>