On Fri, 2 Mar 2007, Michel Meyers wrote: > Wasn't there a difference between 'Concurrent with spooling' and 'really > concurrent as in interlaced'?
Yes. > I seem to recall something as if the > latter wasn't tested/recommended It's fine to lay data to tape using concurrent/interlaced, however restores will be _very_ painful due to massive tape shoeshining as it seeks small distances for each block to recover, resulting in restore down around 1-2MB/s or slower (assuming LTO2) The time penalties for laying data as concurrent/spooled are tiny once there are 2 or more jobs underway (ASSUMING THE SPOOL DISK IS FAST ENOUGH TO KEEP UP![*]), but the speed on restore will be close to the native speed of the tape, assuming no limits imposed by the target disk or intervening network. [*] In order to keep up with 4-6 jobs spooling off remote servers via 1Gb/s connections to 2 FC-connected LTO2 tape drives in a changer, I ended up having to stripe the spool filesystem cross 4 SATA 2 drives - and this only _just_ keeps up. It became pretty clear while benchmarking that I should be looking very hard at a 6-8 disk (or more) stripeset in order to achieve reasonable speeds for any more tape drives, or if we moved to LTO3. The problem with that many drives is that it requires a good dedicated RAID controller and moves out of the realm of general commodity hardware for the backup machine. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
