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 {
# LEOM is not supported for this drive and kernel
comment "Created by amtapetype; compression disabled"
length 2459914240 kbytes
filemark 3227 kbytes
speed 156842 kps
blocksize 2048 kbytes
part-size 200gb
part-cache-max-size 200gb
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 <[email protected]> [20180111 15:44]:
> 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 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
> >><[email protected]> wrote:
> >>
> >>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, but it is really
> >>bad for new drives. You should really think about increasing it a lot.
> >>
> >>Jean-Louis
> >>
> >>On 11/01/18 02:56 PM, Luc Lalonde wrote:
> >>>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
> >>>BufferedMode: yes
> >>>Medium Type: 0x78
> >>>Density Code: 0x5c
> >>>BlockSize: 32768
> >>>DataCompEnabled: no
> >>>DataCompCapable: yes
> >>>DataDeCompEnabled: yes
> >>>CompType: 0xff
> >>>DeCompType: 0xff
> >>>BOP: yes
> >>>Block Position: 0
> >>>Partition 0 Remaining Kbytes: -1
> >>>Partition 0 Size in Kbytes: -1
> >>>ActivePartition: 0
> >>>EarlyWarningSize: 0
> >>>NumPartitions: 0
> >>>MaxPartitions: 3
> >>>
> >>>Further, here's my '/etc/stinit.def':
> >>>
> >>>manufacturer="IBM" model = "ULTRIUM-HH7" {
> >>>scsi2logical=1
> >>>can-bsr=1
> >>>auto-lock=1
> >>>two-fms=0
> >>>drive-buffering=1
> >>>buffer-writes
> >>>read-ahead=1
> >>>async-writes=1
> >>>can-partitions=1
> >>>fast-mteom=0
> >>>sysv=1
> >>>timeout=180
> >>>long-timeout=14400
> >>>mode1 blocksize=32768 compression=1
> >>>mode2 blocksize=32768 compression=0
> >>>mode3 disabled=1
> >>>mode4 disabled=1
> >>>
> >>>Sorry, about that!
> >>>
> >>>On 2018-01-11 02:43 PM, 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 tapetype LTO7 {
> >>>>comment "Created by amtapetype; compression enabled"
> >>>>length 5874932832 kbytes
> >>>>filemark 1813 kbytes
> >>>>speed 118310 kps
> >>>>blocksize 32 kbytes
> >>>>}
> >>>>
> >>>>Why is it saying that it can write roughly 6Tb if it's supposedly
> >>>>hardware compressed? LTO7 is supposed to give a compression ration
> >>>>of 2.5 to 1.
> >>>>
> >>>>I've disabled compression... Here's the ouptut of 'tapeinfo:
> >>>>
> >>>>[root@ulysses ~]# tapeinfo -f /dev/sg12
> >>>>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
> >>>>BufferedMode: yes
> >>>>Medium Type: 0x78
> >>>>Density Code: 0x5c
> >>>>BlockSize: 32768
> >>>>DataCompEnabled: yes
> >>>>DataCompCapable: yes
> >>>>DataDeCompEnabled: yes
> >>>>CompType: 0xff
> >>>>DeCompType: 0xff
> >>>>Block Position: 2
> >>>>Partition 0 Remaining Kbytes: -1
> >>>>Partition 0 Size in Kbytes: -1
> >>>>ActivePartition: 0
> >>>>EarlyWarningSize: 0
> >>>>NumPartitions: 0
> >>>>MaxPartitions: 3
> >>>>
> >>>>Am I missing something?
> >>>>
> >>>>Thanks!|
> >>>>
> >>
> >>Disclaimer
> >>
> >>This message is the property of CARBONITE, INC. and may contain
> >>confidential or privileged information.
> >>
> >>If this message has been delivered to you by mistake, then do not copy or
> >>deliver this message to anyone. Instead, destroy it and notify me by reply
> >>e-mail.
> >>
> >
>
> --
> Luc Lalonde, analyste
> -----------------------------
> Département de génie informatique:
> École polytechnique de MTL
> (514) 340-4711 x5049
> [email protected]
> -----------------------------
--
Jean-Francois Malouin | IT Operations and Infrastructure
McConnell Brain Imaging Centre | MNI | McGill University
3801 University St., Room NW119 | Montreal QC | H3A 2B4 | 514.398.8924
