Date: Tue, 28 Jul 1998 17:19:47 +0200 From: Tor.Egge@fast.no To: karl@mcs.net Cc: current@FreeBSD.ORG Subject: Re: Serious Dump problems Message-ID: <199807281519.RAA12042@pat.idi.ntnu.no> In-Reply-To: Your message of "Tue, 28 Jul 1998 07:35:23 -0500" References: <19980728073523.02311@mcs.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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?199807281519.RAA12042>