From owner-freebsd-current Tue Mar 31 10:44:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id KAA15067 for freebsd-current-outgoing; Tue, 31 Mar 1998 10:44:28 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from sendero.simon-shapiro.org (sendero-fddi.Simon-Shapiro.ORG [206.190.148.2]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id KAA15052 for ; Tue, 31 Mar 1998 10:44:18 -0800 (PST) (envelope-from shimon@simon-shapiro.org) Received: (qmail 21385 invoked from network); 31 Mar 1998 18:53:31 -0000 Received: from localhost.simon-shapiro.org (HELO sendero-fxp0.simon-shapiro.org) (@127.0.0.1) by localhost.simon-shapiro.org with SMTP; 31 Mar 1998 18:53:31 -0000 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Message-ID: X-Mailer: XFMail 1.3-alpha-032398 [p0] on FreeBSD X-Priority: 3 (Normal) In-Reply-To: <199803311826.LAA05074@narnia.plutotech.com> Date: Tue, 31 Mar 1998 10:53:31 -0800 (PST) Reply-To: shimon@simon-shapiro.org Organization: The Simon Shapiro Foundation From: Simon Shapiro To: "Justin T. Gibbs" Subject: Re: CONTINUED problems: Restore/Dump broken? Cc: current@FreeBSD.ORG Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On 31-Mar-98 Justin T. Gibbs wrote: ... > I don't seem to have this problem with dump and restore here. In testing > out the "new" CAM tape driver, we've made several dumps and restores > using > blocksizes much larger than 512bytes. These were usually performed to > either an Archive Python DDS-2 drive or an Exabyte Eliant drive. This is in the current current. Not in CAM. We still have to use it until we all convert to CAM, CAM is in the main branch, etc. > One thing that could be biting you though is that dump defaults to a > 10k block size while restore will default to a 32k block size. I haven't > analyzed the source enough to see if it will properly handle cases where > the blocksize is smaller than the default. I always explicitly specify > the blocksize. As I said before, this happens with cpio too. You do: cd /etc;find . | cpio -H newc -ov -C 65536 -O /dev/nst2.2 then you do: cpio -H newc -ivt -I /dev/nst2.2 -C whatever_you_want And you will get garbage out. In my innocense I assume that the blocking factor to the tape, and the logical blocking of an application can/should be decoupled. It appears that a) they are not, and b) anything other than 512 bytes breaks. Now, this DID work correctly up to some months ago. I checked it, under -current very carefully. since you get NO INDICATION of failure when you WRITE the tapes, there was no reason for me (and others) to check again. Maybe it is busted only with the Sony. Maybe not. I'll put an HP drive on one of the systems here today and see what it does. ---------- Sincerely Yours, Simon Shapiro Shimon@Simon-Shapiro.ORG Voice: 503.799.2313 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message