Date: Tue, 5 May 1998 13:00:25 -0700 (PDT) From: Tom <tom@sdf.com> To: Karl Pielorz <kpielorz@tdx.co.uk> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: dump/restore broken? Message-ID: <Pine.BSF.3.95q.980505125103.22578C-100000@misery.sdf.com> In-Reply-To: <354F6D1D.47530E6C@tdx.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 5 May 1998, Karl Pielorz wrote: > Tom wrote: > > > > > 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 be a bit more specific... So, your saying that if I run > a dump - and then later go to restore it, or check what's on a previously > 'dumped' tape by running: > > restore t That is exactly what I'm saying. You should look at bin/4683. I didn't report this one, but this poster believes it is sparse file problem. I don't think I'm backing up any sparse file on my filesystem (just user data). > It's going to barf? - Because it doesn't on my system... It's never barfed Then you don't have the "hole in map" problem. But when you do, you won't like it much, as dump will create a damaged archive, then restore will almost immediately croak reading it. > on a 't' - and only once on a restore (but that as I've already said) was > due to bad termination... That shouldn't happen. Do you have parity turned on both the controller and the tape drive? > Regards, > > Karl Pielorz 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.980505125103.22578C-100000>