From owner-freebsd-hackers Tue May 5 18:39:54 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA28275 for freebsd-hackers-outgoing; Tue, 5 May 1998 18:39:54 -0700 (PDT) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp03.primenet.com (root@smtp03.primenet.com [206.165.6.133]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA28238 for ; Tue, 5 May 1998 18:39:44 -0700 (PDT) (envelope-from tlambert@usr02.primenet.com) Received: (from daemon@localhost) by smtp03.primenet.com (8.8.8/8.8.8) id SAA28125; Tue, 5 May 1998 18:23:59 -0700 (MST) Received: from usr02.primenet.com(206.165.6.202) via SMTP by smtp03.primenet.com, id smtpd028006; Tue May 5 18:23:46 1998 Received: (from tlambert@localhost) by usr02.primenet.com (8.8.5/8.8.5) id SAA20824; Tue, 5 May 1998 18:23:37 -0700 (MST) From: Terry Lambert Message-Id: <199805060123.SAA20824@usr02.primenet.com> Subject: Re: Network problem with 2.2.6-STABLE To: tom@sdf.com (Tom) Date: Wed, 6 May 1998 01:23:37 +0000 (GMT) Cc: tlambert@primenet.com, beng@lcs.mit.edu, freebsd-hackers@FreeBSD.ORG In-Reply-To: from "Tom" at May 5, 98 09:16:19 am X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > > > Perhaps, but dump/restore is broken for large filesystems. Perhaps one > > > of the dump/restore advocates should fix it before a new user is swayed by > > > the rhetoric into using dump/restore, only to watch restore core dump on > > > large dumps. > > > > Be happy to. Where is you real bug report that details the problem, > > instead of just stating that there is one? So far, all I have seen > > Posted Apr 16 to freebsd-stable. The only response that I received was > from someone that said, "thats just like the PR that I sent a long time > ago". > > 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. 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. More likely, you have broken SCSI termination, a dirty tape drive, are using cheap video tapes in place of expensive data tapes (and hoping it works), or a you have broken tape drive/driver that needs you to pad blocks to tape block boundries because the hardware is too stupid to read partial blocks. are you perhaps using an older HP DAT drive, before they added the lockout to keep you from using tapes not capable of accurately holding the data? You can ignore your damaged media using the "-y" option to restore: -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. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message