On Tuesday 10 January 2006 00:34, Arno Lehmann wrote:
> Hello,
>
> On 1/10/2006 12:03 AM, Kern Sibbald wrote:
> > On Monday 09 January 2006 21:49, Chris Hunter wrote:
>
> ...
>
> > My results are:
> > 23:31:54 Begin writing Bacula records to tape ...
> > ...
> > Wrote blk_block=290000, dev_blk_num=2000 VolBytes=18,708,412,456
> > rate=20973.6 KB/s Wrote blk_block=295000, dev_blk_num=7000
> > VolBytes=19,030,972,408 rate=21005.5 KB/s Wrote blk_block=300000,
> > dev_blk_num=12000 VolBytes=19,353,532,352 rate=21059.3 KB/s Wrote
> > blk_block=305000, dev_blk_num=1500 VolBytes=19,676,092,296 rate=21021.5
> > KB/s Wrote blk_block=310000, dev_blk_num=6500 VolBytes=19,998,652,248
> > rate=20984.9 KB/s Wrote blk_block=315000, dev_blk_num=11500
> > VolBytes=20,321,212,192 rate=21014.7 KB/s Wrote blk_block=320000,
> > dev_blk_num=1000 VolBytes=20,643,772,144 rate=20979.4 KB/s ...
> > btape: btape.c:2335 End of tape 31:0. VolumeCapacity=21,474,880,104.
> > Write rate = 20869.7 KB/s 23:49:03 Done filling tape at 31:0. Now
> > beginning re-read of tape ...
> >
> > And it wrote 21.474 GB in 17min 9 seconds, which works out to about
> > 20.867 MB/sec by my calculations, and that corresponds to the rates shown
> > above by btape. This is pretty reasonable IMO because btape is in fact
> > writing "records" to blocks as Bacula does, then writing the blocks to
> > tape. The records are generated by starting with random data from
> > /dev/random,
>
> That might be something to consider - some random-data sources (or
> rather pseudo-random number generators - are actually *slow* This might
> be something that depends on the distribution you use.
>
> Check what btape really uses (look in the source, use strace or use
> lsof, for example) and measure its speed: 'time dd if=/dev/random
> of=/dev/null bs=64k count=256' for example. Try different sources for
> random - /dev/randomand /dev/urandom or /dev/hwrandom might be possible
> devices to use.
The interesting thing is that without this random data (called only once in
the beginning, then "mixed" for subsequent records), the transfer rates can
become astronomically large. This is because with data such as zeros, the
drive is able to compress it down to almost nothing and hence from Bacula's
stand point, the transfer rate goes way up. With my mixed-random data, it
appears to pretty much disable any compression, thus giving a more "real" raw
transfer rate for the device. It also tends to give a more real byte
capacity of the drive, not that it is really very important ...
--
Best regards,
Kern
(">
/\
V_V
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
