On Friday 05 October 2007 12:25, Ralf Gross wrote: > Kern Sibbald schrieb: > > > Update: > > > > > > With dd and different block sizes I get 100-115 MB/s (bs=64k to > > > 256k). This was only a simple test with the new LTO-4 drive. Changing > > > the bs to more than 128 didn't result in better performance. > > > > > > A simple test with tar was much slower (~60 MB/s, didn't touch the > > > bs). > > > > > > I didn't test bacula with other bs than the default, but I get ~77 > > > MB/s for a backup of a file on the sd (fd/sd on the same server) where > > > the LTO-4 drive is connected to (Attribute Spooling enabled, just one > > > 20 GB file). > > > > This seems to confirm what I have been saying that the 64K block size is > > not so bad (128K may be better for an LTO-4), and increasing the block > > size to many megabytes as proposed by some people probably won't improve > > performance (and IMO may increase tape errors). > > Yes, I haven't found any improvement with bs > 128K. > > > > I'm not sure why backup to LTO-4 isn't faster than the backup to > > > LTO-4, but the result is not that bad. > > > > I assume you meant the second LTO-4 to be LTO-3. The answer to your > > question is that you are probably talking about different systems, so > > they are almost impossible to compare, and even if you are talking about > > the same system, as I understand you need RAID disks to be able to drive > > an LTO-4 at full speed, or multiple disks and multiple simultaneous jobs. > > From what I understand maximum LTO-4 transfer speeds are significantly > > faster than most disk speeds. > > Well, the LTO-3 drive is connected to a different server/sd, but the > hardware is almost identical (Xeon 3000, 4 GB RAM). The 20 GB file was > backed up from a RAID device which is capable of 130 MB/s seq. reads > (tiobench). But I found a thread somewhere that you have to use > multiple streams to get max. speed with LTO-4. Although I don't > understand why this should be necessary if the backup source is able > to deliver 130 MB/s and dd is able to write to tape with 110MB/s.
Yes, the thread that you read is correct. The problem is that even though the source can deliver 130MB/s and the tape can write at 110MB/s, the total throughput you get when you hook the two together in a single thread is not even 110MB/sec. I haven't done technical performance management for over 20 years, so I forget the formulas for calculating this, but basically, you must wait to get data from the disk, then wait to write it to the tape, and that slows down both. To run at full speed, you need two threads, one that reads from disk and buffers in memory, then a second thread that writes to tape. With that, you can get almost the speed of the slowest device. Such multiple threading multiple buffering techniques have been long planned for Bacula (since the beginning in 2000), but until the advent of LTO-3 and LTO-4 have not been really necessary ... > > I won't complain at all that ~80 MB/s is slow, just wondering where I > could tune the system or bacula to get somewhere near 100-120 MB/s > which LTO-4 (in theory) should be able to write to tape. Yes, it is possible with additional code. See above. This will be implemented in a future version ... > > Note: my backup over GbE was nearly as fast as the backup from disk on > the local sd (~77 MB/s). > > If you have to backup multiple TB, every single MB/s counts ;) Yes, agreed. :-) > > Ralf > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Bacula-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/bacula-devel ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
