Re: amanda-3.4.5 does not fill one tape

2020-05-13 Thread Jon LaBadie
On Wed, May 13, 2020 at 06:17:02PM +0200, Stefan G. Weichinger wrote:
> Now look at this run of
> 
> "amtapetype -b 128k /dev/nst0"
> 
> with another tape, FUJI instead of HP:
> 
> define tapetype LTO3-fuji {
> comment "Created by amtapetype; compression disabled"
> length 284180096 kbytes
> filemark 20803 kbytes
> speed 38376 kps
> blocksize 128 kbytes
> }
> 
> ~290 GB ... faster, and large filemarks.
> 
> Maybe that drive is somehow failing .. ?

I wasn't sure what LEOM was.  I assume it is "Logical End of Media".

Anyway I came across two references that said need for cleaning
is one reason for getting early EOM.

I'm wondering also if this could be a case of Amanda tapes being
labelled with the mode set to LTO-2 capacity.  I know you check
the mode and it shows 44, but Amanda always reads the tape before
writing.  Could this be setting the mode back to 42 because the
tapes were initially labelled with the mode set incorrectly?

What if you forget about amtapetype and simply use dd to see how
much random data it will write to tape.

Jon
-- 
Jon H. LaBadie j...@jgcomp.com
 11226 South Shore Rd.  (703) 787-0688 (H)
 Reston, VA  20190  (703) 935-6720 (C)


Re: amanda-3.4.5 does not fill one tape

2020-05-13 Thread Debra S Baddorf


> On May 13, 2020, at 11:17 AM, Stefan G. Weichinger  wrote:
> 
> Now look at this run of
> 
> "amtapetype -b 128k /dev/nst0"
> 
> with another tape, FUJI instead of HP:
> 
> define tapetype LTO3-fuji {
>comment "Created by amtapetype; compression disabled"
>length 284180096 kbytes
>filemark 20803 kbytes
>speed 38376 kps
>blocksize 128 kbytes
> }
> 
> ~290 GB ... faster, and large filemarks.
> 
> Maybe that drive is somehow failing .. ?


No real ideas here, but I *DO* recall some failing drives on this list
where the symptom was like this.  Tapes wouldn’t fill.

Anybody else still out there in the aether?

Deb Baddorf
Fermilab



Re: amanda-3.4.5 does not fill one tape

2020-05-13 Thread Stefan G. Weichinger
Now look at this run of

"amtapetype -b 128k /dev/nst0"

with another tape, FUJI instead of HP:

define tapetype LTO3-fuji {
comment "Created by amtapetype; compression disabled"
length 284180096 kbytes
filemark 20803 kbytes
speed 38376 kps
blocksize 128 kbytes
}

~290 GB ... faster, and large filemarks.

Maybe that drive is somehow failing .. ?


Re: amanda-3.4.5 does not fill one tape

2020-05-13 Thread Stefan G. Weichinger
Am 13.05.20 um 09:03 schrieb Stefan G. Weichinger:

> It looks like a LTO2 tape ... although the customer told me it says LTO3
> on the cartridge (and has a correct product number).
> 
> mt status detects it as density=0x44 as well, but the capacity and speed
> looks like LTO2.
> 
> Strange.

Some more info:

# tapeinfo  -f /dev/nst0
Product Type: Tape Drive
Vendor ID: 'HP  '
Product ID: 'Ultrium 3-SCSI  '
Revision: 'Q51D'
Attached Changer API: No
SerialNumber: 'HU11339W0G'
MinBlock: 1
MaxBlock: 16777215
SCSI ID: 4
SCSI LUN: 0
Ready: yes
BufferedMode: yes
Medium Type: Not Loaded
Density Code: 0x44
BlockSize: 0
DataCompEnabled: no
DataCompCapable: yes
DataDeCompEnabled: yes
CompType: 0x1
DeCompType: 0x1
Block Position: 1
Partition 0 Remaining Kbytes: 400308
Partition 0 Size in Kbytes: 400308
ActivePartition: 0
EarlyWarningSize: 0
NumPartitions: 0
MaxPartitions: 0



Re: amanda-3.4.5 does not fill one tape

2020-05-13 Thread Stefan G. Weichinger


Retried amtatpetype with another new tape yesterday.

No success.

Labelled and tested with 64k blocksize, still about 200 GB size only.

Could the older kernel somehow play a role here?

The output of amtapetype says:

"LEOM is not supported for this drive and kernel"

I try to set "LEOM false" now explicitly.

Linux version 3.12.13-gentoo ... yeah, I know ...

But the server is ~3 hrs away and old, reinstallation without guarantees
is somehow inefficient.

(No IRMC/ILO remote console for doing kernel change easily)

-

It looks like a LTO2 tape ... although the customer told me it says LTO3
on the cartridge (and has a correct product number).

mt status detects it as density=0x44 as well, but the capacity and speed
looks like LTO2.

Strange.