Date: Wed, 6 May 1998 01:23:37 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: tom@sdf.com (Tom) Cc: tlambert@primenet.com, beng@lcs.mit.edu, freebsd-hackers@FreeBSD.ORG Subject: Re: Network problem with 2.2.6-STABLE Message-ID: <199805060123.SAA20824@usr02.primenet.com> In-Reply-To: <Pine.BSF.3.95q.980505090835.21978C-100000@misery.sdf.com> from "Tom" at May 5, 98 09:16:19 am
next in thread | previous in thread | raw e-mail | index | archive | help
> > > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805060123.SAA20824>