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
part-cache-type disk part-cache-dir "/holddisk" } Maybe it's overkill, 512k might give you the full perf of the drive. Don't have a LTO7 to play with but I hope this helps! jf * Luc Lalonde <luc.lalo...@polymtl.ca> [20180111 15:44]: > Hello Jean-Louis and Debra, > > I'l

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"