Re: [Mondo-devel] [Fwd: Re: Mondo problem-addendum]

[Hugo R. <hug...@ms...>]

Jeffrey Sofferin <je...@jl...> wrote:-
>Still no joy in mudville. The tar processes fill the log with bad tar 
>header messages. I think it's from the biggielist.txt being zero size on my 
>machine?

Are any other users on this mailing list experiencing this particular 
problem ('bad tar header')?

Which tape streamer are you using, Jeffrey?

I suspect there is something wrong with the way the tape streamer reacts to 
fopen()/fread()/fclose() calls from the kernel. Mondorestore does this:-

# dd if=/dev/st0 bs=131072 count=256 2> /dev/null | tar -zxv

In reply, tar does this:-

>tmp/mondo-restore.cfg
>tmp/mountlist.txt
>tmp/filelist.full
>tmp/biggielist.txt
>tar: Bad tar header, skipping
>[...]

Looks OK so far. :) Tar is warning you that it's getting a lot of zeroes 
instead of archives. However, it has successfully extracted the files 
required by the calling subroutine, which means you may ignore the 'bad tar 
header' messages.

>Buffer has been STARTED.
>Opening IN tape
>Skipping data disks on stream
>Restoring from fileset #0 (4864 KB) on media #1
>[...]
>afio: "/tmp/tmpfs/afio.tmp.6": Premature input EOF
>Warning - errors reported by afio

The afio archive restored from tape ended early. Either mondorestore ran out 
of (ram)disk space or the tape streamer doesn't like the way mondorestore 
reads data from it. The latter is common in OnStream drives. Which tape 
drive do you have?

>afio: "/tmp/tmpfs/afio.tmp.50": Premature input EOF

There's another one.

>Wrong marker! (Should be BLK_STOP_AN_AFIO_OR_SLICE, is actually BLK_UNKNOWN 
>(572548464))
>Bad header block at 2048768 K

This suggests you have a bad tape. I'm sure you've checked the tapes 
already, so I'm assuming there's a bad interaction between your tape 
streamer and the Linux kernel. That's the usual cause.

We've been able to work around most of the problems with the more eccentric 
tape streamers by using a 32KB block size when reading/writing to/from 
tapes. In your case, it's not working.

From the website:-

"Stan Benoit owns a Python SCSI DDS-2, a Python SCSI DDS-3 and an IDE 
Colorado/Travan. They all work fine with the latest 1.4x and 1.5x releases. 
The latest 1.5x gave some trouble in Nuke Mode but it offered to run in 
Interactive Mode instead, Troff accepted and everything went smoothly after 
that."

(He tested 1.6x on his tape drives a few days ago & confirmed to me that 
mondorestore ran fine.)

"Maurice Janssen has an HP DAT8i tape drive (DDS-2) which backs up and 
compares OK with 1.4x/0.6x."

(Maurice, does 1.6x also work on your HP DAT8i drive?)

"Mark Newman has an Onstream ADR2.60 ide drive which does not work with 
1.5x, although it does work with 1.4x; this is strange, very strange. Do any 
other Onstream users have comments to add or stories to tell?

I (Hugo) own a couple of HP IDE Colorado/Travan drives, which have behaved 
perfectly with 1.4x and 1.5x; that is to be expected. The hardware which I 
own is likely to play well with software I have written. ;)"

So, OnStream drives don't work but most HP drives do. It's very odd.

Is it related to the block size of 32K? What if you change 
INTERNAL_BLOCK_SIZE in mondo/common/my-stuff.h from 32768 to, say, 65536 or 
even 16384?

The funny thing is, if we disregard the 'bad tar header' messages, 
mondorestore is able to read the archives from tape... mostly. Occasionally, 
there's a hiccup. It's as if there's a problem with ram disk space. I rule 
out afio: it's very stable. I would like to rule out the kernel-level tape 
driver module. Really, I think it's either the tape streamer itself or the 
kernel-level tape driver module. The latter has to grit its teeth & tolerate 
an awful lot of crap from the former.

-Hugo


_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE* 
http://join.msn.com/?page=features/virus