* Kern Sibbald schrieb am 20.09.07 um 11:07 Uhr:
> On Thursday 20 September 2007 00:59, Arno Lehmann wrote:
> > Hi,
> >
> > 18.09.2007 16:25,, Marc Schiffbauer wrote::
> > > * Chris Howells schrieb am 18.09.07 um 16:14 Uhr:
> > >> Hi,
> > >>
> > >> Marc Schiffbauer wrote:
> > >>
> > >> Finally got around to messing around with bacula again...
> > >>
> > >>> The manual says that nnn being the same number for both settings
> > >>> means "fixed" blocksize.
> > >>>
> > >>> As I understand it, your solutions should be to just set the
> > >>> "Minimum Block Size" so you get a good perfromance.
> > >>>
> > >>> Minimum Block Size = 1048576
> > >>
> > >> Unfortunately just setting a Minimum Block Size does not work. btape for
> > >> instance will not work then. It dies with a glibc error. (See end of
> > >> mail for full trace.
> >
> > Interesting. On a FreeBSD 7 system with Bacula 2.2.4 btape crashes
> > when I use larger block sizes. I haven't found the actual limit, but
> > 512k blocks work, 1MB sized ones don't.
>
> Bacula currently limits block sizes to 1MB. This limit was implemented 7
> years ago when the fastest drive was a DLT. I will increase the size, but I
> am quite skeptical about writing block sizes of 1 or 2 Megabytes. I believe
> that you may get a bit more speed, but you will probably increase the rate of
> errors -- unless drive technology has progressed more than I am aware of.
I never heard of such errors in current (enterprise) drives that
depend on the blocksize being too large.
Other commercial enterprise backup solutions do reliable backups
with maximum drive speed, so this seems not to be a problem. If it was I
would call this crappy hardware.
The thing is if bacula is too slow in writing to tapes this might be a
showstopper for large environments because this a) wears the drive
("shoe-shining") and b) will make backups run way too long.
Why do you limit the blocksize at all? I suggest setting a
reasonable default, but let it to the user to configure blocksizes
whichever she wants. This way bacula will be fit for future
drives... maybe we have drives with blocksizes of 20MB or 30MB in a
few years...
>
> By the way, increasing the Minimum Block Size is NOT the way to increase the
> Maximum block size. In general one should *never* set the minimum block size
> unless you have an older brain damaged drive. In increasing the Minimum
> Block Size, you virtually guarantee to waste tape for no good reason. The
> way to increase the maximum block size is to use the Maximum Block Size
> directive, which I previously thought was rather obvious ... oh well.
It is, at least to me. But the thing was to really increase the
minimum blocksize to increase speed.
Where is this wasting space? If you write 200GB to a tape and the
last block is only one byte in size you have wasted nearly 2MB of
space, right?
-Marc
--
BUGS My programs never have bugs. They just develop random
features. If you discover such a feature and you want it to
be removed: please send an email
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bacula-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/bacula-devel
