Re: "bad status on taper SHM-WRITE (dumper)" message

On Friday 01 January 2021 15:23:47 you wrote:
copied the list too, in case Nathan wants to chime in.

> On Fri, Jan 01, 2021 at 08:19:00AM -0500, Gene Heskett wrote:
> > On Wednesday 30 December 2020 02:06:41 Jon LaBadie wrote:
>
> ...
>
> > I've captured the amstatus outout, would you like to see it?
> > attached...
>
> What I'm really looking for is when/if it fails again, how/if the
> amstatus output differs.

aha, tonights saved amstat, normally a bit over 10k, is only 44 bytes!
copy/pasted:
root@coyote:amstat.d$ ls -l
total 64
-rw-r--r-- 1 amanda amanda 10112 Dec 31 05:15 amstat-201231-0515
-rw-r--r-- 1 amanda amanda 10112 Dec 31 05:24 amstat-201231-0524
-rw-r--r-- 1 amanda amanda 10112 Dec 31 05:25 amstat-201231-0525
-rw-rw-r-- 1 gene   gene   10112 Jan  1 02:38 amstat-210101-0238
-rw-r--r-- 1 amanda amanda 10112 Jan  2 02:22 amstat-210102-0222
-rw-r--r-- 1 amanda amanda    44 Jan  3 02:36 amstat-210103-0236
root@coyote:amstat.d$ cat amstat-210103-0236
Using: /usr/local/var/amanda/Daily/amdump.1

finally, a clue! but of what? I've not a clue...

> RE the current amstatus, the tape lines are weird:
>
>   taped       :  78   13029m   12942m (100.68%) (100.68%)
>     tape 1    :  78   13029m   13029m ( 15.15%) Dailys-39 (78 parts)
>
> It is obviously talking about one tape so I'd expect the lines
> to match numerically.  But the percentages particularly do not.
>
I have this again, it left the dump, I assume the first failed 
/home/gene in the holding disk in 2 parts because the crc failed
on the first try, but it retried it again, but copied both 
00014.coyote._home_gene.1 AND 00015.coyote._home_gene.1 to the
/amandatapes/Dailys/data link. With a 2 minute difference in
files creation times.

So I ram cmp with a boatload of options to see where they were diff,
which they were, getting if I hadn't got tired of watching it fly by,
nearly a 100% difference in the first 400 megs.

Since this error existed on a spinning rust holding disk, and now on a 
240Gig SSD, I'm inclined to point a finger at gzip -best, but am open
to other explanations too.

The next question that points to is best answered by untaring that indice.tar.

Boiling that down to size with grep as follows:
root@coyote:data$ tar -tf indices.tar | grep /_home_gene/20210103 -
returns:
usr/local/var/amanda/Daily/index/coyote/_home_gene/20210103020105_1.header
usr/local/var/amanda/Daily/index/coyote/_home_gene/20210103020105_1.state.gz
usr/local/var/amanda/Daily/index/coyote/_home_gene/20210103020105_1-unsorted.gz

Which doesn't look like a double dump to me. Other explanations welcome.

The two files in /amandatapes/Dailys/data, aren't quite the same size either:
from an ls -l:
-rw------- 1 amanda amanda 2547835625 Jan  3 02:14 00014.coyote._home_gene.1
-rw------- 1 amanda amanda 2548295549 Jan  3 02:16 00015.coyote._home_gene.1

> My most recent one doesn't match either, so must be normal:
>
>   taped       :  28   56238m   57697m ( 97.47%) ( 97.47%)
>     tape 1    :  28   56238m   56238m ( 54.92%) DS1-158 (33 parts)
>
>
> Jon
To heck with it, I'm going back to bed.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>