Re: Amtapetype wrongly reporting compression?

2018-01-15 Thread Gene Heskett
On Monday 15 January 2018 08:11:37 Jean-Louis Martineau wrote: > Luc, > > You should keep the driver in variable block size: > eg . /usr/bin/mt -f /dev/st0 setblk 0 > > Jean-Louis > > On 12/01/18 03:20 PM, Luc Lalonde wrote: > > Hello Gene, > > > > Would a variant like this: > > > >

Re: Amtapetype wrongly reporting compression?

2018-01-15 Thread Jean-Louis Martineau
amtapetype report the drive is in compressed mode because it can write compressible data a lot faster than uncompressible data. amtapetpye write uncompressible data to determine the size, that's why you get the native tape size. It is also strange that it report 'LEOM is not supported', i'm

Re: Amtapetype wrongly reporting compression?

2018-01-15 Thread Jean-Louis Martineau
Luc, You should keep the driver in variable block size: eg . /usr/bin/mt -f /dev/st0 setblk 0 Jean-Louis On 12/01/18 03:20 PM, Luc Lalonde wrote: Hello Gene, Would a variant like this: /usr/sbin/mtx load 1 0; /usr/bin/mt -f /dev/st0 compression 0; /usr/bin/mt -f

Re: Amtapetype wrongly reporting compression?

2018-01-12 Thread Gene Heskett
On Friday 12 January 2018 15:20:51 Luc Lalonde wrote: > Hello Gene, > > Would a variant like this: > >     /usr/sbin/mtx load 1 0; >     /usr/bin/mt -f /dev/st0 compression 0; >     /usr/bin/mt -f /dev/st0 setblk 524288; >     /usr/bin/dd if=/dev/zero of=/dev/st0 bs=512k

Re: Amtapetype wrongly reporting compression?

2018-01-12 Thread Jon LaBadie
On Fri, Jan 12, 2018 at 03:20:51PM -0500, Luc Lalonde wrote: > Hello Gene, > > Would a variant like this: > >     /usr/sbin/mtx load 1 0; >     /usr/bin/mt -f /dev/st0 compression 0; >     /usr/bin/mt -f /dev/st0 setblk 524288; >     /usr/bin/dd if=/dev/zero of=/dev/st0 bs=512k

Re: Amtapetype wrongly reporting compression?

2018-01-12 Thread Luc Lalonde
Hello Gene, Would a variant like this:     /usr/sbin/mtx load 1 0;     /usr/bin/mt -f /dev/st0 compression 0;     /usr/bin/mt -f /dev/st0 setblk 524288;     /usr/bin/dd if=/dev/zero of=/dev/st0 bs=512k count=1;     su amandabackup -c "/usr/sbin/amlabel -f Monthly-LTO7

Re: Amtapetype wrongly reporting compression?

2018-01-11 Thread Gene Heskett
On Thursday 11 January 2018 14:43:49 Luc Lalonde wrote: > Hello Folks, > > I'm wondering if there's a bug with 'Amtapetype' (version 3.5.1). > > We're migrating from LTO5 to LTO7 and I'm getting strange results when > I run 'amtapetype'. > > Here's what I get after roughly 35 hours: > > define

Re: Amtapetype wrongly reporting compression?

2018-01-11 Thread Jean-Francois Malouin
Hi, I have been using a 2048k blocksize on LTO5 and LTO6 for a few years now with good results. This is the tapetype that amtapetype generated with a non-compression LTO6 tape device (without the part-* options, they are of my own design) using this blocksize: define tapetype lto6-tapetype {

Re: Amtapetype wrongly reporting compression?

2018-01-11 Thread Luc Lalonde
Hello Jean-Louis and Debra, I'll re-run the 'amtapetype' with 512k blocksize and get back to soon (depending on how long it takes) Thanks your your help, Luc. On 2018-01-11 03:31 PM, Debra S Baddorf wrote: After research, I started using 512k blocks, 3 years ago, for LTO5 tapes. For LTO7

Re: Amtapetype wrongly reporting compression?

2018-01-11 Thread Debra S Baddorf
After research, I started using 512k blocks, 3 years ago, for LTO5 tapes. For LTO7 I might have to research even more, but certainly 512k or bigger. Debra Baddorf Fermilab > On Jan 11, 2018, at 2:09 PM, Jean-Louis Martineau > wrote: > > Luc, > > amtapetype use

Re: Amtapetype wrongly reporting compression?

2018-01-11 Thread Jean-Louis Martineau
Luc, amtapetype use speed heuristic to detect if the drive is in compressed mode, it might not be good for newer drives. Why you didn't post the complete amtapetype output? I can't tell you why the heuristic is bad without those numbers. The default block size of 32k was good 15 years ago,

Re: Amtapetype wrongly reporting compression?

2018-01-11 Thread Luc Lalonde
I sent the wrong output in the last email Here's the correct 'tapeinfo': Product Type: Tape Drive Vendor ID: 'IBM ' Product ID: 'ULTRIUM-HH7 ' Revision: 'G9Q1' Attached Changer API: No SerialNumber: '123456789A' MinBlock: 1 MaxBlock: 8388608 SCSI ID: 4 SCSI LUN: 0 Ready: yes

Amtapetype wrongly reporting compression?

2018-01-11 Thread Luc Lalonde
Hello Folks, I'm wondering if there's a bug with 'Amtapetype' (version 3.5.1). We're migrating from LTO5 to LTO7 and I'm getting strange results when I run 'amtapetype'. Here's what I get after roughly 35 hours: define tapetype LTO7 { comment "Created by amtapetype; compression enabled"