From: ivanr@melbourne.sgi.com (Ivan Rayner)
Date: Sat, 9 Jun 2001 15:09:37 +1000
To: Russel Ingram <ringram@gargoylecc.com>
cc: <linux-xfs@oss.sgi.com>
Subject: Re: xfsdump, paride tape, and -m option
In-Reply-To: <Pine.LNX.4.33.0106082248490.23581-100000@localhost.localdomain>
Message-ID: <Pine.SGI.4.32.0106091457360.191765-100000@omen.melbourne.sgi.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

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


-- 
Ivan Rayner
ivanr@melbourne.sgi.com