From owner-freebsd-hackers Tue May 5 23:27:03 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id XAA21479 for freebsd-hackers-outgoing; Tue, 5 May 1998 23:27:03 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from misery.sdf.com (misery.sdf.com [204.244.213.32]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id XAA21450 for ; Tue, 5 May 1998 23:26:52 -0700 (PDT) (envelope-from tom@sdf.com) Received: from tom by misery.sdf.com with smtp (Exim 1.82 #3) id 0yWxFh-0006Mk-00; Tue, 5 May 1998 23:00:25 -0700 Date: Tue, 5 May 1998 23:00:25 -0700 (PDT) From: Tom To: Terry Lambert cc: beng@lcs.mit.edu, freebsd-hackers@FreeBSD.ORG Subject: Re: Network problem with 2.2.6-STABLE In-Reply-To: <199805060123.SAA20824@usr02.primenet.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 6 May 1998, Terry Lambert wrote: > > Anyhow, basically any kind of restore operation (restore -t, or > > restore -r) results in an immediate "hole in map" response, with a "abort? > > [yn]" prompt, and then about three seconds later, a segmentation fault. > > > I think you need to read the man pages. In what man page is "hole in map" mentioned? > A hole in a map won't happen unless you have bad media. If you > traceback the panic in the source code, you'll see that the problem > is a zero-valued block map. Question: why does it segfault several seconds after producing the "abort?" prompt? It had already detected the "hole in map" problem? Regardless this is still a bug, even assuming that the media is bad (it isn't, as I did a full backup and restore to the media with tar). ... > You can ignore your damaged media using the "-y" option to restore: Doesn't do anything in this case. A "restore -t -v -y" tells me that every file (at least those I bother to let it read) had CRC errors. That isn't right, as I can use the same tape to do a full tar and untar with no problems. > -y Do not ask the user whether to abort the restore in > the event of an error. Always try to skip over the > bad block(s) and continue. > > It is recommended that you, instead, fix the underlying problem. What is that? The only thing you've said, is bad tape. But it isn't. Next. > 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