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.
|