On 24/10/14 08:30, Jean-Francois Malouin wrote: > * Jon LaBadie <[email protected]> [20141023 16:59]: >> On Thu, Oct 23, 2014 at 04:28:01PM +1100, Tom Robinson wrote: >>> Now I have to work out why my tape is reporting as smaller! amtapetype >>> reports my tape is only half >>> as big for the same block size...(was 1483868160 is now 743424512). :-/ >>> >>> 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. >>> >>> >> Note it is not only reporting the lower size, but dumps >> are experiencing it as well. >> >> IIRC, you are using an LTO-5. My peek at the web says >> that format can record at up to 280Mbps. You are now >> only seeing 58Mbps. Is that a big change from your >> previous runs? >> >> Feeding a drive too slowly, i.e. below its ability to >> stream continuously, can reduce the apparent capacity >> of the tape. >> >> If this is the case you may have to find ways to >> increase the data flow rate to your drive. >> >> Jon >> -- >> Jon H. LaBadie [email protected] >> 11226 South Shore Rd. (703) 787-0688 (H) >> Reston, VA 20190 (609) 477-8330 (C) > Stepping in, I miss the earlier comments so maybe this is not > appropriate or OT, in which case just toss me in the dust bin. > > Your length and speed are way off. > > This is my tapetype for a HP Ultrium LTO-5 > > define tapetype tape-lto5 { > comment "Created by amtapetype; compression disabled" > length 1480900608 kbytes > filemark 3413 kbytes > speed 107063 kps > blocksize 2048 kbytes > part-size 100gb > part-cache-max-size 100gb > part-cache-type disk > part-cache-dir "/holddisk" > } > > In this case, amtapetype disappointedly reported only ~100MBs (native > speed per specs is 140MBs) but in my local setup I frequently see > values up to 300MBs with 'averaged xfer rate' around the specs value, > eg, see the attached munin graph of my holdding disk performance from > last night run, the green line is data from the holdding disk to the > tape. LTO-5 will stream from 40MBs (I think) to 150Mbs, lower than > that you're shoe-shinning. > > If the data xfer from the holdding disk to the drive can sustain the max > xfer data rate to the drive (140MBs) this suggest you have a dud or > experiencing other hardware issues. I would test the hardware directly > without amanda in the way using native OS tool, dd or whatever you > fancy.
Quite possibly the tape driver is at fault. I'm using a generic SCSI Tape driver (st) together with the SCSI Generic dirver (sgen) for the tape library. I tried installing the IBMtape driver, but failed to get it to work on OmniOS.
signature.asc
Description: OpenPGP digital signature
