Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 6 May 1998 19:31:56 -0700 (PDT)
From:      Tom <tom@sdf.com>
To:        Terry Lambert <tlambert@primenet.com>
Cc:        beng@lcs.mit.edu, dec@phoenix.its.rpi.edu, freebsd-hackers@FreeBSD.ORG
Subject:   Re: Network problem with 2.2.6-STABLE
Message-ID:  <Pine.BSF.3.95q.980506191159.28352A-100000@misery.sdf.com>
In-Reply-To: <199805070232.TAA19518@usr01.primenet.com>

next in thread | previous in thread | raw e-mail | index | archive | help

On Thu, 7 May 1998, Terry Lambert wrote:

> >   What?  Was something about my message unclear?  restore dies with a
> > "hole in map".  You can also search the PR database for that phrase to
> > find an indentical report to the one I filed.
> 
> You are assuming that the "hole in map" is there because dump put it
> there (which is unlikely), or because there was actually a hole in
> the map, faithfully copied (which is unlikely, but possible, if you
> partition didn't pass fsck prior to dump).

  Another possibility:  restore gets confused and sees a hole that isn't
there.

  The filesystem was just newfs'ed, and had an another tape untar'red on
to it.  It is clean.

...
> Tar does not complain about bad tape blocks, because it can't consistency
> check them, having no check fields.  It will happily write zeroed blocks
> into your files.

  The files were verfied (they were copies from another system, so this is
easy to do).

> Restore is more sensitive to the problem, because restore requires
> that the referential integrity of the files written to disk be intact.

  Except that restore complains about "hole in map" before restoring a
single file, or writing anything at all.

...
> > > Which driver is responsible for that controller?
> > 
> >   ahc
> 
> With or without the CAM patches?

  They are not available.

> > > What exact model of tape drive are you using?
> > 
> >   Quantum DLT 4000
> > 
> > > What exact brand of tapes are you using?
> > 
> >   Quantum DLT IV
> 
> You are positive you are using the st/mt command to select a block size
> for this before starting the dump, right?
> 
> DAT drives are notoriously finicky about default block size selection.

  DLT not DAT.  Even on DAT, I haven't seen a drive that didn't work with
the standard variable blocksize setting.

  Also, my DLT is very quick to inform me of blocksize problems if I don't
read the tape back with the right block size too.

> >   You know what a much better test would be?  I can do a dump, read the
> > first hundred megs or so with dd into a file, and send it to you.  Since
> > "restore -t" reports the "hole in map" within seconds, it obviously hasn't
> > read very far into the tape yet, so doing a restore from a disk file
> > should have the same result.

  I've tested this.  I read back the first 100MB back as "dd if=/dev/rst0
bs=10k count=1000 of=tapefile", then did a "restore -t -f tapefile".

> Or better, you could dump to a disk instead of to a tape, then also dump
> to a tape, and then do an MD5 checksum of the images and see if they match,
> in order to isolate it to "tape or software" vs. "disk or software".
> 
> Also, a partial dump should exhibit the same problems, since "it
> obviously hasn't read very far into the tape yet".  Which means

  Yes.  I did a dump to a file on another filesystem, and aborted it after
about 300MB.  Doing a "restore -t -f tapefile2" also results in an
immediate "hole in map" and a segfault.

...
> 					Terry Lambert
> 					terry@lambert.org
> ---
> Any opinions in this posting are my own and not those of my present
> or previous employers.
> 
> 

Tom


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95q.980506191159.28352A-100000>