Re: Odd error from amcheck

Debra S Baddorf <[email protected]> Wed, 17 Apr 2019 23:00:11 +0000
Newsgroups gmane.comp.archivers.amanda.devel
Message-ID <[email protected]>

> On Apr 17, 2019, at 5:40 PM, Jon LaBadie <[email protected]> wrote:
> 
> On Wed, Apr 17, 2019 at 06:24:42PM +0000, Debra S Baddorf wrote:
>> 
>> 
>>> On Apr 17, 2019, at 12:15 PM, Jason L Tibbitts III <[email protected]> wrote:
>>> 
>>> I had a bit of downtime with my backup server (not related to Amanda)
>>> and after getting things running again I've seen a couple of odd
>>> problems related to labels.
>>> 
>>> Today I got the following from amcheck:
>>> 
>>> NOTE: Holding disk '/local/amanda/work': 7461020 MB disk space available, using 7460920 MB
>>> slot 19:amcheck-device: TypeError in method 'storage_getconf', argument 1 of type 'storage_t *' at /usr/lib64/amanda/amcheck-device line 165.
>>> 
>>> That corresponds to this block of code:
>>> 
>>>               } elsif ($dev->status & $DEVICE_STATUS_VOLUME_UNLABELED and
>>>                        $dev->volume_header and
>>>                        $dev->volume_header->{'type'} == $Amanda::Header::F_WEIRD) {
>>>                   my $autolabel = storage_getconf($storage, $STORAGE_AUTOLABEL);
>>>                   if ($autolabel->{'non_amanda'}) {
>>>                       print STDERR " contains a non-Amanda volume\n";
>>>                   } else {
>>>                       print STDERR " contains a non-Amanda volume; check and relabel it with 'amlabel -f'\n";
>>>                   }
>>> 
>>> which would seem to suggest that it's finding the tape to be unlabeled.
>>> And last night in order to get things to run, I had to relabel a tape.
>>> But these tapes have all been previously labeled, and in fact I've been
>>> using them for a while.  I have no idea what could cause them to become
>>> unlabeled, besides the obvious cause of something writing to them.  But
>>> the tape in slot 19 was just loaded and hasn't been in the drive in some
>>> time.
>>> 
>>> If I run amtape inventory, it tells me
>>> 
>>> [...]
>>> slot 18: label C00018 barcode C00018L6 [retention-tapes]
>>> slot 19: blank barcode C00019L6
>>> slot 20: label C00020 barcode C00020L6 [retention-tapes]
>>> [...]
>>> 
>>> but... it was fine and had a label last night.  And I have a feeling
>>> that tape C00020 will end up being unlabeled tomorrow.
>>> 
>>> Has anyone seen anything like this?  What's the magic incarnation to
>>> read the amanda label from a tape without running amanda tools?  (I know
>>> dd should do it but I can't seem to find the right combination of
>>> options.)
>>> 
>>> - J<
>> 
>> 
>> mt -f /dev/nst0   rewind
>> dd if=/dev/nst0   of=MyFile   bs=512k   
>> mt -f /dev/nst0   rewind     !! so ready for amanda to use it
>> 
>> for   /dev/nst0   substitute the location of your drive   (grep amanda.conf  to find it)
>> 
>> for bs=512k   you may have to guess higher or lower (if an older, smaller tape).
>> This is usually the hardest part to guess at.
>> 
>> 
>> Then do     more MyFile
>> read the first block   and ^Q   out of the rest.   
>> 
>> Mine shows    
>> AMANDA: TAPESTART DATE 20190204200001 TAPE ad5-daily-123
>> ^L
>> 
> 
> Isn't the amanda tape header data still 32KB?  I thought you
> could skip syncronizing dd block size and actual tape bs.
> 
> For example:
> 
>  # dd if=/dev/???? of=MyFile bs=32k count=1
> 
> Skip the "of=MyFile" to write to stdout/screen.
> 
> I think you would have to synchronize the bs of dd and the
> tape if you wanted to read file data from the tape.  But
> not the 1st 32KB.
> 
> Jon
> -- 
> Jon H. LaBadie                 [email protected]
> 11226 South Shore Rd.          (703) 787-0688 (H)
> Reston, VA  20190              (703) 935-6720 (C)

Can it do mixed block sizes on the same tape?   Cuz I know the rest of my blocks are 512k,
possibly by my choice.   For LTO5 tapes.    (I had read that larger tapes need a larger block size.)
Oh here it is:   
grep  BLOCK_SIZE   amanda.conf
      device-property "BLOCK_SIZE"  "512k"   # from man amanda-changers.7
to see what block size you are using.   If you don’t find the term,  then perhaps it’s a default 32k
The “from man amanda-changers.7”  was a note to myself.


When I omit  the blocksize,  I get  “Cannot allocate memory”:
     dd: reading `/dev/nst0': Cannot allocate memory
which isn’t an obvious error, but always goes away when I find the right blocksize to specify.

It fails to read ANY blocks, until I get the right blocksize.    I’m only looking
at the tape-label   first file.   I think the tape-label uses the block size you’ve specified, for the whole tape.

dd if=/dev/nst0  bs=512k    works fine  (straight to standard out)
dd if=/dev/nst0                    fails, and gets the above error.   For me.


Deb Baddorf