On Friday 07 November 2008 13:19:45 Ralf Gross wrote: > Kern Sibbald schrieb: > > On Thursday 06 November 2008 22:47:41 Ralf Gross wrote: > > > Alex Chekholko schrieb: > > > > On Wed, 5 Nov 2008 16:12:51 +0100 > > > > > > > > Kern Sibbald <[EMAIL PROTECTED]> wrote: > > > > > For writing to tape (providing it is LTO-n) I strongly recommend a > > > > > block size not to exceed 256K. > > > > > > > > Hi Kern, > > > > > > > > Why do you say that? Is this thread relevant?: > > > > http://www.mail-archive.com/[email protected]/msg012 > > > >46.h tml > > > > > > > > Also, I would like to corroborate the OP's experiences; I had an > > > > almost identical thread about small block size and slow write speed: > > > > http://www.nabble.com/LTO-4-performance--td17407840.html > > > > > > > > In fact, I was unable to get higher block sizes working at all with > > > > btape: > > > > http://www.adsm.org/lists/html/Bacula-users/2008-05/msg00504.html > > > > > > > > So I am still stuck at ~22MB/s writing to LTO-4 with the default > > > > block size. > > > > > > I don't think that the blocksize is the problem. I did some tests but > > > couldn't get higher results with larger blocksizes. I get 75-85 MB/s > > > with the default bs and no additional tuning. > > > > That is probably correct, but most likely only because you have a > > bottleneck elsewhere -- probably in one of the points I mentioned. The > > speed is always capped by the slowest component. Once you remove the > > other bottlenecks on your system, the blocksize will very likely become > > the bottleneck and then you can measure the difference. > > I didn't want to compain, just show the org. poster that his 22 MB/s > are likely not a bs issue. > > That being said, I started a thread on the user list a while ago where > I aked what throughput people are getting when writing to tape. Nobody > involved in this thread got higher numbers than 80-85 MB/s for a > single job.
That is probably reasonable for one job, but if you are writing to an LTO-2,3, or 4, we know that with multiple simultaneous jobs it is possible to get write speeds of 150 MB/sec. Kern > > I backup directly over GbE interfaces from a RAID that can deliver 350 > MB/s. Network throughput is ~115 MB/s and we are mainly backing up > very large files. Setting Maximum Network Buffer Size and other > options didn't make any difference to the default values. Spooling > dind't help, in fact it was slower during despooling because the spool > disks are slower than the GbE network + the RAID of the client. > > I know that the developer list is not the perfect place for this, but > maybe someone here can share his numbers? What overhat will bacula add > to the transferred data? > > Thanks, Ralf > > > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge Build the coolest Linux based applications with Moblin SDK & win > great prizes Grand prize is a trip for two to an Open Source event anywhere > in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Bacula-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/bacula-devel ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Bacula-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bacula-devel
