My original message was:
"> I've performed a vdump on my alpha server 4100 (running DU 4.0D,
aggregate
> > patchkit 2) with TLZ6L-DA tape drive using the following command:
> >
> > vdump -D -Cuv -f /dev/rmt0h /u01
> >
> > Now I'm trying to vrestore to my alpha server 2100 (running DU 4.0D,
> > aggregate patchkit 2) with an HP SureStore 6000 tape drive using the
> > following command:
> >
> > vrestore -xv -f /dev/rmt0h -D /u01
> >
> > I keep receiving the following error message when trying to perform the
> > restore:
> >
> > vrestore: Date of the vdump save-set: Wed Jan 13 14:46:00 1999
> > vrestore: ino_tbl_add_dir(97700); parent ino not found
> >
> > I resolved my earlier issues regarding the different types of tape
> drives
> > that I'm using, and I've successfully performed vdumps and vrestores
> between
> > the two. The only difference between my tests and now is that the tests
> were
> > at most one gig in size. Now I'm performing a vdump that is around 9 gig
> and
> > spanning three 4mm tapes.
> >
> > Can anyone tell me what is going wrong?"
>
>
Dr. Tom Blinn came through with the following reply:
"I think you're hitting either a vdump or a vrestore bug. ino_tbl_add_dir
is a
> routine in vrestore/inotbl.c source code. It gets called during
> processing of
> the input to add a directory entry to an internally maintained table, and
> there seems to be logic checking to make sure the parent directory is
> already
> in the internally built table.
>
> One of the first things it does is call a routine called ino_tbl_lookup()
> to
> look for the dir's parent's inode number, and if it's not found, you get
> the
> error message you report.
>
> if (dir_ino != parent_ino) {
> /* we are not adding the root dir */
>
> parent_ent = ino_tbl_lookup( parent_ino );
> if (parent_ent == NULL) {
> fprintf(stderr, catgets(catd, S_INOTBL1, INOTBL1, "%s:
> ino_tbl_add_dir(%d); parent ino not found\n"),
> Prog, parent_ino );
> exit( 1 );
> }
>
> if (parent_ent->type != DIR_ENT) {
> fprintf( stderr, catgets(catd, S_INOTBL1, INOTBL2, "%s:
> ino_tbl_add_dir(%d); parent not dir ino\n"),
> Prog, parent_ino );
> exit( 1 );
> }
> }
>
> I don't know why this is happening, but it could be related to using the
> "-D"
> switch on the save/restore.
>
> Is /u01 a mount point by any chance? If so, then maybe you don't need to
> use
> the -D and maybe using it confuses vdump (or vrestore) so that you don't
> get
> all the right information written in the saveset.
>
> Have you tried running vrestore with the -t option (or I think there is
> some
> other option that reads the tape and dumps information about what's on the
> tape). That might provide some additional clues.
>
> But, unfortunately, I think you may have hit a vdump/vrestore bug."
>
>
I started my vdump over, but this time I'm doing much smaller dumps. I've
cut it up into about 6 dumps of just over 1 gig. So far I've executed three
of the dumps and I'm currently restoring the first dump. Perhaps this will
be worked out with one of the next patches.
-Stephen Spalding
Received on Fri Jan 15 1999 - 08:24:22 NZDT