On Tue, Jul 13, 2010 at 04:14:17PM -0500, Dustin J. Mitchell wrote:
> Hmm, 14 parts and 14 "Error writing to fd 5" messages. From my memory
> and a brief look at the 2.6.1 sources (I couldn't find a version in
> the thread, but this looks like 2.6.1 to me), that wouldn't have come
> from Amanda itself, but from something Amanda ran - perhaps the
> decompression binary? You said you disabled custom_compress - is this
> an uncompressed dump?
Yes I'm on 2.6.1
It's a gzip dump, this is my config:
define dumptype habackup_archive {
comment "HABACKUP_ARCHIVE"
program "GNUTAR"
property "NO-UNQUOTE" "yes"
tape_splitsize 40Gb
split_diskbuffer "/tapehold/"
fallback_splitsize 10Gb
index
priority high
auth "bsd"
}
>
> The problem is this: all of the parts are concatenated onto the same
> file descriptor - so if the descriptor (a pipe to amandad in this
> case) gets closed prematurely, and amidxtaped somehow failed to notice
> this, then it would make sense to see the remaining parts trigger the
> same failure.
>
> The logs you posted do not have five tapes, but your original problem
> statement said "when it gets to the 5th tape".. are these two
> different failures?
No, I snipped the log to make it more friendly for the mailing list. It
get's all the way to the 5th tape, then those errors came up. In my
numerours runs, I've never been able to retrieve anything with
amrecover past the 1st tape.
>
> Dustin
>
> --
> Open Source Storage Engineer
> http://www.zmanda.com
