Received: (from mail@localhost) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) id f595JYJL024663 for linux-xfs-outgoing; Fri, 8 Jun 2001 22:19:34 -0700 X-Authentication-Warning: linux-xfs.sgi.com: mail set sender to owner-linux-xfs@oss.sgi.com using -f Received: from roujin.gargoylecc.com (roujin.gargoylecc.com [65.100.85.34]) by linux-xfs.sgi.com (8.12.0.Beta5/8.12.0.Beta5) with SMTP id f595JW3D024653 for ; Fri, 8 Jun 2001 22:19:32 -0700 Received: from roujin.gargoylecc.com ([65.100.85.34] ident=ringram) by roujin.gargoylecc.com with esmtp (Exim 3.13 #1) id 158osH-00025O-00; Sat, 09 Jun 2001 13:58:21 -0600 Date: Sat, 9 Jun 2001 13:58:20 -0600 (MDT) From: Russel Ingram To: Ivan Rayner cc: Subject: Re: xfsdump, paride tape, and -m option In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-xfs@oss.sgi.com Precedence: bulk On Sat, 9 Jun 2001, Ivan Rayner wrote: > On Fri, 8 Jun 2001, Russel Ingram wrote: > > > On Sat, 9 Jun 2001, Ivan Rayner wrote: > > > > > On Sat, 9 Jun 2001, Russel Ingram wrote: > > > > > > > I'm using xfsdump from cvs (I think it is from 5/30/01 but might be > > > > 6/5/01) to attempt to backup an xfs filesystem to an HP Colorado 8GBe > > > > parallel tape drive. Every time I try to use the -m option (the > > > > parallel tape driver is a very minimal tape device driver and suggests > > > > specifying 16k as the block size) xfsdump core dumps with the following > > > > error: > > > > > > > > drive_minrmt.c:1820: do_get_write_buf: Assertion 'contextp->dc_nextp < > > > > contextp->dc_recendp' failed. > > > > > > > > Is this a bug or just an incompatiblity with the minimalness of the pt > > > > driver? > > > > > > If you can mail the complete xfsdump command line, I'll see if I can > > > reproduce the problem here. > > > > > okie dokie, here's what I was giving it: > > > > xfsdump -m -b 16 -o -l0 -E -F -M"gumby" -L"home" -s home -f /dev/pt/0 / > > > > Like I said its a parallel tape drive that I haven't got anything else to > > work with either (tar works but not to the expected capacity) so it may > > just be a problem in the device driver but since it core dumps without > > even trying to dump I thought someone might be interested in if it turned > > out to be a bug with xfsdump. > > The argument to -b should be bytes, so 16k would be 16384 not 16. > > If this doesn't fix your problem, could you use -v5 to get verbose output. > (This might produce alot of output, so you should redirect it to a file.) > > Ivan It wasn't clear (to me anyway) what the syntax on the -b option was supposed to be to get 16k blocksize, so thanks. I'll give it a try sometime tomorrow and get back to ya. -- Russ Ingram Gargoyle Computer Consulting (307)742-1361 www.gargoylecc.com