Craig White wrote: > On Wed, 2009-01-07 at 17:57 +0100, Ralf Gross wrote: >> T. Horsnell schrieb: >>> Ralf Gross wrote: >>>> Ferdinando Pasqualetti schrieb: >>>>> I think you should use /dev/random, not /dev/zero unless hardware >>>>> compression is disabled in order to have more realistic figures. >>>> This wouldn't be a good idea, /dev/random or /dev/urandom are just too >>>> slow in generating random data. To test the nativ speed of the drive >>>> creating a file from /dev/urandom and writing this file then from >>>> tmpfs or a fast disk to the drive would be much better. >>>> >>>> >>>> Ralf >>> Personally, I'd use /dev/zero with compression turned off. >>> Then there's *nothing* between the data-source and the tapedrive. >> Yes, but most people use hardware compresion with LTO drives. Sooner >> or later he has to test the drive with compression. > ----
> funny thing is that amanda developers are adamant that you disable > hardware compression and use software compression instead. > > Obviously it takes longer and more cpu power to compress the files in > software before storing them on the tape and if you leave hardware > compression on and use software compression too, the files probably grow > in size. > > Commercial backup software just seems to always use hardware > compression. IMO, using hardware compression makes it very difficult to investigate performance problems. I spent a long time investigating my LTO4 performance, varying the blocking factor, with and without hardware compression, and with and without software compression, on an otherwise idle box. I never reached any firm conclusions. It seemed to me that hardware compression could result in the tapedrive mechanism not being fed data fast enough to keep it streaming at full speed, since the records may be shortened by the compression process, whereupon it would slow down a bit by bit in order to avoid stopping altogether (a really bad thing which results in shoe-shining motion) until the data rate increased again, at which point it would accelerate. Without an increase in that data rate, some threshold would be reached whereby the drive buffer was exhausted and the tape would then begin stop-start/ing, and thus *really* slow down. If you feed it with pre-compressed data, assuming you can compress fast enough (which neither gzip nor bzip could if my LTO4 tests were anything to go by) then the above process doesnt happen, and the tape can run at full speed always. My feeling also, is that faster drives can sometimes result in slower throughput because of the increased likelyhood of this stop-start. Cheers, Terry ------------------------------------------------------------------------------ Check out the new SourceForge.net Marketplace. It is the best place to buy or sell services for just about anything Open Source. http://p.sf.net/sfu/Xq1LFB _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
