Tom Robinson IT Manager/System Administrator MoTeC Pty Ltd
121 Merrindale Drive Croydon South 3136 Victoria Australia T: +61 3 9761 5050 F: +61 3 9761 5051 E: [email protected] On 24/10/14 09:23, Jon LaBadie wrote: > 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. Sorry, I've copied the wrong output. Last year I did do the amtapetype test specifying block size 512 kbytes. Here's what I got last year: Checking for FSF_AFTER_FILEMARK requirement Applying heuristic check for compression. Wrote random (uncompressible) data at 85721088 bytes/sec Wrote fixed (compressible) data at 295261525.333333 bytes/sec Compression: enabled Writing one file to fill the volume. Wrote 1519480995840 bytes at 85837 kb/sec Got LEOM indication, so drive and kernel together support LEOM Writing smaller files (15194390528 bytes) to determine filemark. device-property "FSF_AFTER_FILEMARK" "false" define tapetype ULT3580-TD5 { comment "Created by amtapetype; compression enabled" length 1483868160 kbytes filemark 868 kbytes speed 85837 kps blocksize 512 kbytes } # for this drive and kernel, LEOM is supported; add # device-property "LEOM" "TRUE" # for this device. The recent test with amtapetype is also specifying block size of 512 kbytes: 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. As to what has changed, about 25 days ago (September 31, 2014) we upgraded the OS (prompted by issues unrelated to backup) but the tape performance was already suffering degradation before that (starting in August with degradation from 117% (2014-08-10) to 86% tape capacity the following week, then steadily declining weekly by week to 57.6%, 56.6%, 42.9%, 54.4%, etc., remaining at about 56%, ...). Some speed tests with dd: $ dd if=/dev/zero of=/data/backup/amanda/file1 bs=1024k count=2048 2048+0 records in 2048+0 records out 2147483648 bytes (2.1 GB) copied, 1.34568 s, 1.6 GB/s $ time dd if=/data/backup/amanda/file1 of=/dev/rmt/0b bs=512k count=4000 4000+0 records in 4000+0 records out 2097152000 bytes (2.1 GB) copied, 13.4122 s, 156 MB/s real 0m13.427s user 0m0.015s sys 0m1.519s $ time dd if=/data/backup/amanda/file1 of=/dev/rmt/0b bs=512k count=4000 4000+0 records in 4000+0 records out 2097152000 bytes (2.1 GB) copied, 13.4404 s, 156 MB/s real 0m13.456s user 0m0.014s sys 0m1.471s $ time dd if=/dev/zero of=/dev/rmt/0b bs=512k count=4000 4000+0 records in 4000+0 records out 2097152000 bytes (2.1 GB) copied, 8.24686 s, 254 MB/s real 0m8.262s user 0m0.011s sys 0m0.297s $ time dd if=/dev/zero of=/dev/rmt/0b bs=512k count=4000 4000+0 records in 4000+0 records out 2097152000 bytes (2.1 GB) copied, 8.1345 s, 258 MB/s real 0m8.150s user 0m0.011s sys 0m0.299s t.
signature.asc
Description: OpenPGP digital signature
