Received: (from majordomo@localhost) by oss.sgi.com (8.11.2/8.11.3) id f5D2Y6219816 for linux-xfs-outgoing; Tue, 12 Jun 2001 19:34:06 -0700 Received: from sgi.com (sgi.SGI.COM [192.48.153.1]) by oss.sgi.com (8.11.2/8.11.3) with SMTP id f5D2Y4P19813 for ; Tue, 12 Jun 2001 19:34:05 -0700 Received: from larry.melbourne.sgi.com (larry.melbourne.sgi.com [134.14.52.130]) by sgi.com (980327.SGI.8.8.8-aspam/980304.SGI-aspam: SGI does not authorize the use of its proprietary systems or networks for unsolicited or bulk email from the Internet.) via SMTP id TAA06366 for ; Tue, 12 Jun 2001 19:34:00 -0700 (PDT) mail_from (ivanr@melbourne.sgi.com) Received: from omen.melbourne.sgi.com (omen.melbourne.sgi.com [134.14.55.139]) by larry.melbourne.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id MAA02857; Wed, 13 Jun 2001 12:32:44 +1000 From: ivanr@melbourne.sgi.com (Ivan Rayner) Received: from localhost (ivanr@localhost) by omen.melbourne.sgi.com (SGI-8.9.3/8.9.3) with ESMTP id MAA14818; Wed, 13 Jun 2001 12:32:43 +1000 (EST) X-Authentication-Warning: omen.melbourne.sgi.com: ivanr owned process doing -bs Date: Wed, 13 Jun 2001 12:32:43 +1000 To: Russel Ingram 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 Tue, 12 Jun 2001, Russel Ingram wrote: > On Wed, 13 Jun 2001, Ivan Rayner wrote: > > > Well, even if it is a hardware problem, it'd be nice if xfsdump didn't > > core dump. Would you be able to send me the output of 'xfsdump -v5 ...' > > and the core file? > > I can't seem to get the error messages to redirect to the file so here are > the error messages I got this time: > > sh: xfsdq: command not found > sh: xfsdq: command not found These errors indicate that xfsdq/xfsrq weren't installed. If you want your quota information included in the dump, you should install them. I think they're part of the xfsdump package. If you don't care, then you can ignore these errors. > xfsdump: drive_minrmt.c:2201: do_end_write: Assertion `first_rec_w_err >= > 0' failed. > Aborted (core dumped) It looks as though the following code failed with errno == 22 (Invalid argument): cmd/xfsdump/common/drive_minrmt.c: rval = ioctl( fd, MTIOCTOP, &mop ); if ( rval < 0 ) { /* failure */ mlog( MLOG_DEBUG | MLOG_DRIVE, "tape op %s %d returns %d: errno == %d (%s)\n", printstr, param, rval, errno, strerror( errno )); return -1; } where mop.mt_op == MTWEOF and mop.mt_count == 1, which later triggered the assertion failure and core dump. In other words, your hardware/driver didn't want to write an end-of-file record. You could try running 'mt weof 1' from the command line to verify my assertion. What driver does your tape drive use? You could possibly take a look at the source and see how it handles the MTIOCTOP (MTWEOF) ioctl. For example, you can see the scsi tape driver code for this at linux/drivers/scsi/st.c line 2223. Ivan -- Ivan Rayner ivanr@melbourne.sgi.com