Re: Release of amanda-2.5.0b2

On Thu, Jan 19, 2006 at 07:31:08PM -0500, Jean-Louis Martineau wrote:

> The Amanda core team is pleased to announce the release of Amanda
> 2.5.0b2. It is stable and we hope to release 2.5.0 soon. test it and
> report it if you find a bug in this release.

I have one (or two?) more issue here.

Below, I tried to amfetchdump host.do.main:/m/b.  Only full dumps were
done of this DLE.  This DLE is available seven times on the tapes:

   lv  dumpdate  chunks on tape
a. 0   20060204  VOL08:7,  VOL08:8,  VOL08:9, VOL09:1, VOL09:1
b. 0   20060204  VOL10:1,  VOL10:2,  VOL10:3, VOL10:4, VOL10:5
c. 0   20060205  VOL10:10, VOL10:11, VOL01:1, VOL01:2, VOL01:3
d. 0   20060205  VOL02:7,  VOL02:8,  VOL02:9, VOL03:1, VOL03:2
e. 0   20060205  VOL04:1
f. 0   20060207  VOL04:7,  write aborted due to full tape.
g. 0   20060207  VOL05:1

Tapings a..d were done with tape_splitsize=500mb
Tapings b, d and e were done by autoflush because of bug#1425436.
All dumps are compressed.

Below is a transcript attached.  There are several problems I see here:

1. VOL05:1 (this is the newest non-broken available dump) is _not_
   considered for retrieval at all.

2. Instead, amfetchdump _tries_ to get the (broken) VOL04:7.

3. But instead of VOL04:7 it gets the (older) VOL04:1.  There seems to be
   no attempt to further search for VOL04:7

4. The order of tapes seems to be wired.  I would have expected
      VOL05 VOL02 VOL03 VOL10         (how they were sceduled)
   or VOL05 VOL04 VOL10               (last available for every dumpdate)
   or VOL05 VOL10 VOL01 VOL08 VOL09   (first available for every dumpdate)
   or some such.

5. When trying to append the second chunk to the first one, amfetchdump
   fails with "Bad file descriptor".  The resulting dump (uncompressed)
   is 527620009 bytes long.

6. Next problem is with amrecover, but it seems to be closely related 
   with the "Bad file descriptor" problem.  Unfortunately, I don't have a
   transcript for this problem, because the system crashed.  Here's the
   description:

   When I tried to retrieve the above mentioned DLE mentioned in line c
   with amrecover, the system (Athlon 1800+, 500MB RAM, 2G swap,
   suse-10.0) freezed, but vterm switching and pinging from a different
   host worked.  This reminds me of overcommitments caused by memory-hogs.

   After reboot, I noticed following file in the slot-directory
   of the vtape directory:

    -rw-------   1 amanda disk 527630347 Feb  7 07:52 info

   Notice that the length is almost the same as in 5. This file starts with
   following contents:

position 0
AMANDA: FILE 20060205 raven.wolf.local /m/b  lev 0 comp .gz program /bin/tar
To restore, position tape at start of file and run:
        dd if=<tape> bs=32k skip=1 |     /usr/bin/gzip -dc |   /bin/tar -f... -


   Notice the first line "position 0" which seems to be the original
   contents of the info file.  At position 32779 (that is,
   strlen("position 0\n")+32kb) starts a tar file which turns out to be
   the first chunk of the dump I tried to restore.

   This looks like amrecover writes the dump to the wrong file descriptor.
   The error message from amfetchdump looks as if amfetchdump has a similar
   problem.


Here is the transcript:

host:/ # amfetchdump ppc host.do.main /m/b
5 tape(s) needed for restoration
changer: got exit: 0 str: 4 10 1 1
The following tapes are needed: VOL04 VOL02 VOL10 VOL01 VOL03
Press enter when ready

Looking for tape VOL04...
changer: got exit: 0 str: 4 10 1 1
changer_query: changer return was 10 1 1
changer_query: searchable = 1
changer_find: looking for VOL04 changer is searchable = 1
changer_search: VOL04
changer: got exit: 0 str: 4 file:/m/amchanger/ppc
amfetchdump: slot 4: date 20060207 label VOL04 (exact label match)
Scanning VOL04 (slot 4)
amfetchdump:   1: restoring FILE: date 20060205 host host.do.main disk /m/b lev 
0 comp .gz program /bin/tar
amfetchdump: Search of VOL04 complete
Looking for tape VOL02...
changer: got exit: 0 str: 4 10 1 1
changer_query: changer return was 10 1 1
changer_query: searchable = 1
changer_find: looking for VOL02 changer is searchable = 1
changer_search: VOL02
changer: got exit: 0 str: 2 file:/m/amchanger/ppc
amfetchdump: slot 2: date 20060206 label VOL02 (exact label match)
Scanning VOL02 (slot 2)
amfetchdump:   7: restoring split dumpfile: date 20060205 host host.do.main 
disk /m/b part 1/5 lev 0 comp .gz program /bin/tar
amfetchdump:   8: restoring split dumpfile: date 20060205 host host.do.main 
disk /m/b part 2/5 lev 0 comp .gz program /bin/tar
amfetchdump:      appending to host.do.main._m_b.20060205.0.1
restore: write error: Bad file descriptor

gzip: stdin: unexpected end of file
host:/ #