Hi,
Le vendredi 21 janvier 2011 17:55:50, vous avez écrit :
I am finding that amcheckdump (3.2.0) gets sporadic failures with messages
like
Reading volume AMB009L4 file 9
Validation errors:
Error writing to fd 9: Broken pipe
/bin/gzip exited with status 1
maybe you should check the logs to have the gzip error message ?
A similar problem was reported in
http://www.mail-archive.com/amanda-users < at > amanda.org/msg44288.html
but I'm not sure whether it is meant to be fixed in 3.2.0.
In my configuration tar is not involved, the backup files are in
compressed dump format. So amcheckdump creates a pipe containing gzip and
restore; presumably gzip terminates when it gets to the end of the real
data and does not bother reading the zero padding at the end of the last
block. Unlike with tar I don't know any way of forcing gzip to
read till the bitter end.
My blocks are 512kB and they are read over a slowish iscsi connection so
that possibly gives gzip plenty of time to process its data while the
rest of the block is still being read.
I can live with the problem, but it is a bit irritating so any comments
welcome.
Bob
not sure it is related but I had some similar problem when trying to write my
own verification script. I did something like that :
amfetchdump -p -h ... > FETCH_PIPE &
( dd bs=32k of=HEADER_PIPE count=1; dd bs=32k of=DUMP_PIPE; ) <FETCH_PIPE &
cat HEADER_PIPE # parse header to know which tools we need to unpack...
gzip -d <DUMP_PIPE | tar -xf- &
wait
it was 'almost' working with some random failures which looked like yours
(gzip failed because datas are 'not in gzip format' causing amfetchdump to die
with a broken pipe). The strange thing is that a given dump will sometimes
work and sometimes not. I finally discovered that when it fails the header I
get has a wrong size (<32k) so I added 'iflag=fullblock' to the first dd call
and it seems to have solved the problem. Looks like you're not using
amfetchdump yourself but maybe amcheckdump does the same mistake behind your
back ?
Hoping it may help someone...
