On 24/10/14 07:48, Jon LaBadie wrote: > On Thu, Oct 23, 2014 at 10:34:38AM -0400, Gene Heskett wrote: >> On Thursday 23 October 2014 01:28:01 Tom Robinson did opine > ... >> If you are feeding the tape device compressed files, and the drives >> compressor is enabled too, this will quite often cause file expansions on >> the tape itself. The drives compressor, because it is intended to handle >> the compression on the fly, is generally not sophisticated enough to do >> any further compression and will add to the datasize, expanding what >> actually goes down the cable to the drives heads. > Tom is using an LTO drive (-5 I think). Most modern tape > drives, including all LTO's do not exhibit the bad behavior > of the DDS drives with their run-length encoding scheme. > > IIRC, they have enough cpu smarts and memory to first > collect the data in memory, try to compress it to another > another memory buffer, and if it is enlarged the block > is saved "uncompressed". > > Note, instead of a flag at the start of the tape indicating > compressed or uncompressed, there is a flag for each tape > block. > > jl 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 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.
signature.asc
Description: OpenPGP digital signature
