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

Re: [Bacula-devel] MaximumBlockSize Problem and Question


Le Friday 07 November 2008 14:36:46 Kern Sibbald, vous avez écrit :
> 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/msg0
> > > > >12 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

This is with a good hardware compression rate, but it's a very good test, 
IMHO, more than using random data to get only 80MB/sec. If you able to write 
at 150MB/s, i'm pretty sure that you will be able to write at 80MB/s... Even 
if your source file is made with a dd if=/dev/zero, your harddisk, your 
network, your SCSI/SAS or whatever controler have to handle it like real 
data.

Bye

-------------------------------------------------------------------------
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.