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:
> >
> >
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
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
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
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
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
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
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 {
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
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
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,
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
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"
13 matches
Mail list logo