[prev in list] [next in list] [prev in thread] [next in thread] 

List:       amanda-hackers
Subject:    Re: span/split 5.1 -amfetchdump
From:       John Stange <building () nap ! edu>
Date:       2004-03-25 19:35:04
Message-ID: 20040325193504.GC20311 () nap ! edu
[Download RAW message or body]

> I got the following trying to restore from across 2 file: vtapes:
> 
> amfetchdump:  38: restoring split dumpfile: date 20040316 host saga disk 
> /export/ocean07 part 37/38 lev 0 comp .gz program /bin/tar
> amfetchdump:      appending to saga._export_ocean07.20040316.0.01
> amfetchdump: Search of TestRAIT-02 complete
> 
> amfetchdump: slot 2: date 20040316 label TestRAIT-02 (wrong tape)
> amfetchdump: slot 1: date 20040316 label TestRAIT-01 (exact label match)
> Scanning TestRAIT-01 (slot <none>)
> amfetchdump:   1: restoring split dumpfile: date 20040316 host saga disk 
> /export/ocean07 part 38/38 lev 0 comp .gz program /bin/tar
> amfetchdump:      appending to saga._export_ocean07.20040316.0.01
> 
> gzip: stdin: invalid compressed data--format violated
> Error 32 (Broken pipe) offset 32768+32768, wrote 0
> amfetchdump: pipe reader has quit in middle of file.
> 
> Any ideas?  This was a holding file dump so it shouldn't be problem with 
> PORT_WRITE dumps.  Perhaps the original seek wasn't correct?  amdump log:

Yeah, that's the only obvious thing I can come up with from staring at this.
Conveniently enough, I just finished gutting and rewriting that code per our
earlier discussion, so if there's some subtle bug in there that I never found
it might be gone in the next patch revision.

> taper: r: end saga./export/ocean07.20040316.0 part 35, splitting after 
> 1048576 kbytes (next chunk will start at 36701248kb)
> taper: reader-side: got label TestRAIT-02 filenum 36
> taper: r: end saga./export/ocean07.20040316.0 part 36, splitting after 
> 1048576 kbytes (next chunk will start at 37749856kb)
> taper: reader-side: got label TestRAIT-02 filenum 37
> taper: r: end saga./export/ocean07.20040316.0 part 37, splitting after 
> 1048576 kbytes (next chunk will start at 38798464kb)
> taper: reader-side: got label TestRAIT-02 filenum 38
> taper: writing end marker. [TestRAIT-02 ERR kb 39102688 fm 39]
> 
> taper: r: "seeking" input by 38798496kb
> taper: reader-side: got label TestRAIT-01 filenum 1
> driver: result time 16390.492 from taper: DONE 00-00005 TestRAIT-01 1 
> [sec 178.367 kb 811168 kps 4547.7 {wr: writers 25350 rdwait 45.021 
> wrwait 130.855 filemark 2.184}]
> 
> Off by 32kb?  Or is that to skip the header?  Also, the chunk start #'s 
> seem to be incrementing by 1048608, not 1048576 as I'd expect.

Yeah, that's the header skip... the numbers end up looking like they drift from
where the split chunk markers would fall, since it factors the headers into the
file sizes as it tapes.  I didn't want to burden people with remembering the
header size when doing math to figure out how they should size their split
pieces.

> This seems odd too.  The first split file is smaller than the others by 
> 32k.  The holding file header again?  Looking at the sizes on the disk, 
> I'd expect to seek by 37*1048576 = 38797312kb, not 38798496kb.
> 
> -rw-------    1 amanda   disk     1073741824 Mar 16 13:42 
> 00002.saga._export_ocean07.0
> -rw-------    1 amanda   disk           14 Mar 16 13:45 
> 00003-saga._export_ocean07.0
> -rw-------    1 amanda   disk     1073774592 Mar 16 13:45 
> 00003.saga._export_ocean07.0
> -rw-------    1 amanda   disk           14 Mar 16 13:49 
> 00004-saga._export_ocean07.0
> -rw-------    1 amanda   disk     1073774592 Mar 16 13:49 
> 00004.saga._export_ocean07.0
> -rw-------    1 amanda   disk           14 Mar 16 13:52 
> 00005-saga._export_ocean07.0

I vaguely recall that being a normal artifact of some case, but I can't find it
in my test copies so maybe not.  If you can reproduce the set of dumps that led
to this still, it'd be a good thing to test when I finish this round of
coding.

-- 
John Stange, Systems Administrator
National Academies Press
202-334-3514
[prev in list] [next in list] [prev in thread] [next in thread]