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>