On Tue, Feb 07, 2006 at 08:58:30PM +0100, Josef Wolf wrote:
> 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:/ #

Hello!

Are there no opinions about those problems?  I think at least points
5. and 6. are serious problems.  Opinions?