On Fri, Oct 24, 2014 at 08:23:55AM +1100, Tom Robinson wrote:
> Thanks for all the feedback.
>
> Jon is correct, I'm using an LTO5 drive.
>
> Note that, about a year ago I posed this question (and received no response):
>
> Tape Compression: Is it on or off
> (https://www.mail-archive.com/amanda-users%40amanda.org/msg47097.html)
>
> If you read that post, there is a riddle to be answered by checking the tape
> driver flags to
> determine if compression is on or off. I set the driver flags and used a
> 'non-compression' device
> node, as per the man page (/dev/rmt/0bn or BSD style, no-compression,
> no-rewind). All seemed well
> until recently.
>
> For reference, below are my amtapetype outputs from back then and from
> yesterday. Notably,
> compression always reports as 'enabled'. Also, I'm dumping the same,
> compressed DLEs as before. I'm
> not sure compression is the factor here.
>
> Regards,
> Tom
>
As reported on the manpage for amtapetype, the compression enabled
test can be fooled by several factors including very fast drives.
I think the test assumes that tape writing speed is the limiting
factor. Thus uncompressible data approximates the actual write
speed and if more compressible data can be written in the same
time, compression must be enabled.
My LTO experience is limited, but I wonder about block size.
You do not specify a tape block size in your amtapetype runs
(-b <size>) and thus are defaulting to 32KB. Is this also
true in your amdump runs, i.e. do you specify a blocksize in
your tapetype definition?
It is possible you can get better performance using a larger
tape block size. Check it out with a couple of amtapetype runs.
As to the performance, it seems lower than it should be and
lower than it used to be. What has changed? Have you added
more devices to the controller that the LTO-5 drive uses? Is
it still using the same controller? I recall some reports of
amanda users dedicating a high-performance controller to their
LTO drives. Otherwise they couldn't feed the drive as fast as
it could write.
>
> Back then (2014-10-14) amtapetype showed:
>
> $ amtapetype -f -t ULT3580-TD5 weekly /dev/rmt/0bn
> Checking for FSF_AFTER_FILEMARK requirement
> device-property "FSF_AFTER_FILEMARK" "false"
> Applying heuristic check for compression.
> Wrote random (uncompressible) data at 73561559.3650794 bytes/sec
> Wrote fixed (compressible) data at 193099093.333333 bytes/sec
> Compression: enabled
> Writing one file to fill the volume.
> Wrote 1515988615168 bytes at 73464 kb/sec
> Got LEOM indication, so drive and kernel together support LEOM
> Writing smaller files (15159885824 bytes) to determine filemark.
> define tapetype ULT3580-TD5 {
> comment "Created by amtapetype; compression enabled"
> length 1480457632 kbytes
> filemark 0 kbytes
> speed 73464 kps
> blocksize 32 kbytes
> }
> # for this drive and kernel, LEOM is supported; add
> # device-property "LEOM" "TRUE"
> # for this device.
>
> today (2014-10-23) I get:
>
> Checking for FSF_AFTER_FILEMARK requirement
> Applying heuristic check for compression.
> Wrote random (uncompressible) data at 67415370.8307692 bytes/sec
> Wrote fixed (compressible) data at 273874944 bytes/sec
> Compression: enabled
> Writing one file to fill the volume.
> Wrote 761266700288 bytes at 57975 kb/sec
> Got LEOM indication, so drive and kernel together support LEOM
> Writing smaller files (7612661760 bytes) to determine filemark.
> device-property "FSF_AFTER_FILEMARK" "false"
> define tapetype ULT3580-TD5 {
> comment "Created by amtapetype; compression enabled"
> length 743424512 kbytes
> filemark 987 kbytes
> speed 57975 kps
> blocksize 512 kbytes
> }
> # for this drive and kernel, LEOM is supported; add
> # device-property "LEOM" "TRUE"
> # for this device.
>
>
>>> End of included message <<<
--
Jon H. LaBadie [email protected]
11226 South Shore Rd. (703) 787-0688 (H)
Reston, VA 20190 (609) 477-8330 (C)
