[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bacula-devel] MaximumBlockSize Problem and Question


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 <kern@xxxxxxxxxxx> 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/bacula-devel@xxxxxxxxxxxxxxxxxxxxx/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
> Bacula-devel@xxxxxxxxxxxxxxxxxxxxx
> 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
Bacula-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/bacula-devel


This mailing list archive is a service of Copilot Consulting.