> Spooling can reduce overall throughput because the data is > sequentially written to disk and then read back.
This is what got me. I thought it was a buffer to ride out variations in disk read speed (like the mbuffer program) but it's not. The purpose is to get data off clients as fast as possible for later writing to slow tape. Consequently spooling works best when the spool file is large enough to contain one whole tape's worth of data, and you have enough clients backing up that there is always a complete spool file ready to write out to tape. Anything less than this and spooling will slow things down. I think we need a FIFO buffering option in Bacula that will let a few GB of data be buffered in memory, so that the tape doesn't shoe shine when the disks briefly go slow for some reason. I looked at the code for this but it seems like it could be a bit tricky, because you need to return success/fail for each written data block, but you can't really do this if you're caching them for writing later. This is because if there's a write error, it's difficult to handle the error when the block was already written long ago. Cheers, Adam. _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
