xfs
[Top] [All Lists]

Re: xfsdump problems (fwd)

To: Jameel Akari <jakari@xxxxxxxxxxx>
Subject: Re: xfsdump problems (fwd)
From: Simon Matter <simon.matter@xxxxxxxxxxxxxxxx>
Date: Fri, 13 Jun 2003 07:45:46 +0200
Cc: linux-xfs@xxxxxxxxxxx
Organization: Sauter AG, Basel
References: <Pine.OSF.4.33.0306121606070.96412-100000@xxxxxxxxxxxxxxxxxxx>
Sender: linux-xfs-bounce@xxxxxxxxxxx
Jameel Akari schrieb:
> 
> Forgot to reply also to list.. some more followups...
> 
> On Thu, 12 Jun 2003, Axel Thimm wrote:
> 
> > On Wed, Jun 11, 2003 at 03:41:48PM -0400, Jameel Akari wrote:
> > >
> > > xfsdump installed from RPM (from oss.sgi.com),
> > > version 2.2.3-1
> > >
> > > When attempting to run a dump (local or remote) it aborts with:
> > > xfsdump: drive_scsitape.c:1985: do_get_write_buf: Assertion
> > > `contextp->dc_nextp < contextp->dc_recendp' failed.
> 
> > Does this bug also show up with the xfsdump from 
> > http://atrpms.physik.fu-berlin.de/?
> 
> Yes, same result.  I actually need this to work on RH7.3 clients, so 8.0
> RPMS won't help there.
> 
> Interestingly, this is not a problem when using the DLT-IV drive, just the
> 8mm drive.  I backed up about 10GB worth on the DLT-IV without a problem,
> using xfsdump 2.2.3.

I remember similar problems when I tried xfsdump on DAT (DDS3) long time
ago. I don't remember the problem but I remember that I just didn't get
it to work. Using DLT on the same box worked without problem.

Simon

> 
> The 8mm drive seems to work with tar; mt doesn't show anything
> interesting going on.  Could the fact that the 8mm advertises a fixed
> block size and/or is compressed make a difference?  I'm just guessing at
> this point.
> 
> Not to confuse things too much, but I can't get remote backups using ssh
> to work on the DLT drive either.  This is currently more critical than the
> old slow 8mm job.. local backups on the DLT work great; remote with ssh
> gives you:
> ...
> xfsdump: cannot determine tape block size after two tries
> xfsdump: assuming media is corrupt or contains non-xfsdump data
> xfsdump: WARNING: media contains non-xfsdump data or a corrupt xfsdump
> media file header at beginning of media
> 
> It seems that it can't tell what blocksize the device is.. but DLT is
> variable-length blocksize.  I am using the syntax:
> #xfsdump -v5 -f root@spoonman:/dev/st1 /boot
> 
> On the server attached to the DLT I see:
> 
> Jun 11 17:17:04 spoonman kernel: st1: Failed to read 1048576 byte block
> with 245760 byte read.
> 
> If I crank up debugging on the remote xfsdump (RMTSTATUS=2, -v5) I see:
> 
> xfsdump: tape op: opening drive
> rmtopen: RMTHOST(0) = Linux
> rmtcommand: fd = 0, buf = O/dev/st1
> 2
> 
> xfsdump: tape op: get status
> rmtcommand: fd = 0, buf = S
> xfsdump: tape status = bot onl
> xfsdump: hdr_mfilesz 0Mb, min_recmfilesize 0Mb, fsize 256Mb, marksep 16Mb
> xfsdump: recommended tape media file size set to 0x10000000 bytes
> xfsdump: recommended tape media mark separation set to 0x1000000 bytes
> xfsdump: determining tape record size: trying 245760 (0x3c000) bytes
> xfsdump: tape op: get status
> rmtcommand: fd = 0, buf = S
> xfsdump: tape status = bot onl
> xfsdump: tape positioned at BOT: doing redundant rewind
> xfsdump: tape op: rewind 0
> rmtcommand: fd = 0, buf = I6
> 0
> 
> xfsdump: tape op: get status
> rmtcommand: fd = 0, buf = S
> xfsdump: tape status = bot onl
> xfsdump: tape op: reading 245760 bytes
> rmtcommand: fd = 0, buf = R245760
> 
> xfsdump: tape op read of 245760 bytes failed: errno == 12 (Cannot allocate
> memory)
> xfsdump: read returned ENOMEM: trying new record size
> xfsdump: determining tape record size: trying 2097152 (0x200000) bytes
> xfsdump: tape op: get status
> rmtcommand: fd = 0, buf = S
> xfsdump: tape status = onl
> xfsdump: tape position unknown: searching backward for file mark or BOT
> xfsdump: tape op: get fileno
> rmtcommand: fd = 0, buf = S
> xfsdump: In first file, do a rewind to achieve bsf
> xfsdump: tape op: rewind 0
> rmtcommand: fd = 0, buf = I6
> 0
> 
> xfsdump: tape op: get status
> rmtcommand: fd = 0, buf = S
> xfsdump: tape status = bot onl
> xfsdump: tape op: get status
> rmtcommand: fd = 0, buf = S
> xfsdump: tape status = bot onl
> xfsdump: tape positioned at BOT: doing redundant rewind
> xfsdump: tape op: rewind 0
> rmtcommand: fd = 0, buf = I6
> 0
> 
> xfsdump: tape op: get status
> rmtcommand: fd = 0, buf = S
> xfsdump: tape status = bot onl
> xfsdump: tape op: reading 2097152 bytes
> rmtcommand: fd = 0, buf = R2097152
> 
> xfsdump: tape op read of 2097152 bytes short: nread == 1048576
> xfsdump: tape op: get status
> rmtcommand: fd = 0, buf = S
> xfsdump: tape status = onl
> xfsdump: nread less than selected record size on fixed blocksize drive
> indicates wrong blocksize
> xfsdump: cannot determine tape block size after two tries
> xfsdump: assuming media is corrupt or contains non-xfsdump data
> xfsdump: tape op: rewind 0
> rmtcommand: fd = 0, buf = I6
> 0
> 
> xfsdump: tape op: get status
> rmtcommand: fd = 0, buf = S
> xfsdump: tape status = bot onl
> xfsdump: WARNING: media contains non-xfsdump data or a corrupt xfsdump
> media file header at beginning of media
> xfsdump: content.c: 5884: mlog_exit_hint called: hint: CORRUPTION (corrupt
> data encountered)
> 
> The tape is fine; it has locally-generated xfsdumps on it.
> 
> I'm going to try -b 1048576 but that seems wrong somehow.. it really
> should figure it out on its own.


<Prev in Thread] Current Thread [Next in Thread>