Kern Sibbald wrote (2006/02/21): > > One thread would read data and compute md5, the second thread would > > just try to write data to the tape. > This is already the case. Reading the data and computing the md5 sum is done > in the FD, writing the data is done in the SD. Not only are they separate > threads, but they are separate processes.
Oops, I'm sorry - I wanted to say crc32 instead of md5, my fault. I tried to measure time for read(), time for computing crc32 and time for write() and computing crc32 was significant time delay between reading and writing within speed about 80 MB/s on Xeon 3.6 GHz. However now I'm again looking into sources and could find it anymore, if there is secured full data stream by crc32, or just something or nothing anymore. I'll look at it once more. The other point was in that one thread may just read and the second may just write with some memory buffering and synchronization, which can (or yes - can not too) help in feeding data to the tape. This is inspired by star (ftp://ftp.berlios.de/pub/star/), which helped us with performance tunning serveral times in the past. > There are *many* ways to speed up the performance, both external to Bacula > and internal to Bacula. For the moment, internal changes will have to wait > for some contributor because I am still adding essential features. Yes - fully agree. I meant it mainly as that it is good to have it widely known... > Maybe I am not understanding you correctly, but the above is not strictly > true. Depending on how the user configures the SD, there can be one spooling > area per device. I more meant "one spooling area per thread" - if I have allowed maximum N parallel flows storing to bacula-sd, there would be interesting to have 1 to N spool areas, where if despooling is in an action, particular spool area would have an option, that spooling can be paused during this time, so that spool area is reaserved just for reading or just for writing. > This is not generally a problem worth changing since disks > tend tend to be significantly faster than tapes ... The situation is changing since new tape drives have native speed above 50 MB/s, whereas disks are still beaten by moves of heads measured in miliseconds, so the real reading speed from disks is not changing very much over time. > If one really wants tapes to write faster, someone might come up with a patch > to the Bacula SD tape driver that uses overlapped I/O (I think this is > sometimes called asynchronous I/O). I thouhgt about it too, however I not sure how much it would help. I do not belive in OS, SW and HW so much in this way. Regards. -- Rudolf Cejka <cejkar at fit.vutbr.cz> http://www.fit.vutbr.cz/~cejkar Brno University of Technology, Faculty of Information Technology Bozetechova 2, 612 66 Brno, Czech Republic ------------------------------------------------------- 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://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
