-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Kevin Keane wrote:
> Sergio Belkin wrote:
>>> Please always respond to the list...
>>>
>> OK, sorry, I am subscribed to many lists, I don't understand why it
>> not working reply...
>>
> Sourceforge lists are a bit quirky in that when you reply
Alan Brown wrote:
> On Thu, 8 Jan 2009, Chris Hoogendyk wrote:
>
>> In other words the length entered in the tapetype definition is only
>> used for planning and scheduling. The "error" will normally be the end
>> of tape "error", which allows for a variable amount of data actually
>> being wr
Sergio Belkin schrieb:
> Job Report:
>
> 08-Jan 16:40 DirectorandStorageServerThatHasDat72-dir-dir JobId 1975:
> Bacula DirectorandStorageServerThatHasDat72-dir-dir 2.4.2 (26Jul08):
> 08-Jan-2009 16:40:04
> Build OS: i686-redhat-linux-gnu redhat
> JobId: 1975
>
More info about this issue:
Using speedometer during a backup I get this measures:
Server that has Director and Dat 72
TX: 7KB/s
RX: 1,5KB/s
Server that has LTO3:
TX:290 KB/s
RX:3.6 KB/s
Bacula Client:
TX:1.74 MB/s
RX:192 KB/s
Could be the Director server the bottleneck?
Is precisely th
>
> Hi I really appreciate the discussion about advantages and
> disadvantages of compression. But please bear in mind that I am not
> using compression *in anyway*. So please could you help me to solve
> this problem. Below I let you config files (a bit shortened and
> changed in obvious parts l
2009/1/8 Chris Hoogendyk :
>
>
> Alan Brown wrote:
>> On Wed, 7 Jan 2009, Chris Hoogendyk wrote:
>>
>>> Most backup software leaves the responsibility for planning more in the
>>> sysadmin's hands. If the software is just writing data to the tape until
>>> it hits the end of tape and then asking fo
On Thu, 8 Jan 2009, Chris Hoogendyk wrote:
> In other words the length entered in the tapetype definition is only
> used for planning and scheduling. The "error" will normally be the end
> of tape "error", which allows for a variable amount of data actually
> being written to the tape, which would
Alan Brown wrote:
> On Wed, 7 Jan 2009, Chris Hoogendyk wrote:
>
>> Most backup software leaves the responsibility for planning more in the
>> sysadmin's hands. If the software is just writing data to the tape until
>> it hits the end of tape and then asking for another, hardware
>> compressio
On Wed, 7 Jan 2009, John Drescher wrote:
> Do they even say this for LTO4? I mean I have not seen a CPU can
> compress any where near 120MB/s.
I was about to suggest a CUDA setup, but they're only really suitable for
massive or embarrassingly parallel setups, not high speed single threading
stuff
On Wed, 7 Jan 2009, Chris Hoogendyk wrote:
> Most backup software leaves the responsibility for planning more in the
> sysadmin's hands. If the software is just writing data to the tape until
> it hits the end of tape and then asking for another, hardware
> compression is a logical choice.
Part o
On Wed, 7 Jan 2009, T. Horsnell wrote:
> It seemed to me that hardware compression could result in the tapedrive
> mechanism not being fed data fast enough to keep it streaming at full speed,
> since the records may be shortened by the compression process, whereupon
> it would slow down a bit by
On Wed, 7 Jan 2009, Craig White wrote:
> funny thing is that amanda developers are adamant that you disable
> hardware compression and use software compression instead.
Amanda devs are adament about a few things and aren't always correct
Hardware compression on older technologies left a lot to b
John Drescher wrote:
Yes, but most people use hardware compresion with LTO drives. Sooner
or later he has to test the drive with compression.
>>>
>>> funny thing is that amanda developers are adamant that you disable
>>> hardware compression and use software comp
>>> Yes, but most people use hardware compresion with LTO drives. Sooner
>>> or later he has to test the drive with compression.
>>>
>>
>> funny thing is that amanda developers are adamant that you disable
>> hardware compression and use software compression instead.
>>
Do they even say this
Craig White wrote:
> On Wed, 2009-01-07 at 17:57 +0100, Ralf Gross wrote:
>
>> T. Horsnell schrieb:
>>
>>> Ralf Gross wrote:
>>>
Ferdinando Pasqualetti schrieb:
> I think you should use /dev/random, not /dev/zero unless hardware
> compression is disabled
Sergio Belkin wrote:
>> Please always respond to the list...
>>
>
> OK, sorry, I am subscribed to many lists, I don't understand why it
> not working reply...
>
Sourceforge lists are a bit quirky in that when you reply, it puts the
original sender (in this email, Sergio) rather than the ma
Craig White wrote:
> On Wed, 2009-01-07 at 17:57 +0100, Ralf Gross wrote:
>> T. Horsnell schrieb:
>>> Ralf Gross wrote:
Ferdinando Pasqualetti schrieb:
> I think you should use /dev/random, not /dev/zero unless hardware
> compression is disabled in order to have more realistic figures
2009/1/7 Ralf Gross :
> Sergio Belkin schrieb:
>> 2009/1/7 Ralf Gross :
>> > T. Horsnell schrieb:
>> >> Ralf Gross wrote:
>> >> > Ferdinando Pasqualetti schrieb:
>> >> >> I think you should use /dev/random, not /dev/zero unless hardware
>> >> >> compression is disabled in order to have more realist
Craig White schrieb:
> On Wed, 2009-01-07 at 17:57 +0100, Ralf Gross wrote:
> > T. Horsnell schrieb:
> > > Ralf Gross wrote:
> > > > Ferdinando Pasqualetti schrieb:
> > > >> I think you should use /dev/random, not /dev/zero unless hardware
> > > >> compression is disabled in order to have more rea
On Wed, 2009-01-07 at 17:57 +0100, Ralf Gross wrote:
> T. Horsnell schrieb:
> > Ralf Gross wrote:
> > > Ferdinando Pasqualetti schrieb:
> > >> I think you should use /dev/random, not /dev/zero unless hardware
> > >> compression is disabled in order to have more realistic figures.
> > >
> > > This
T. Horsnell schrieb:
> Ralf Gross wrote:
> > Ferdinando Pasqualetti schrieb:
> >> I think you should use /dev/random, not /dev/zero unless hardware
> >> compression is disabled in order to have more realistic figures.
> >
> > This wouldn't be a good idea, /dev/random or /dev/urandom are just too
Ralf Gross wrote:
> Ferdinando Pasqualetti schrieb:
>> I think you should use /dev/random, not /dev/zero unless hardware
>> compression is disabled in order to have more realistic figures.
>
> This wouldn't be a good idea, /dev/random or /dev/urandom are just too
> slow in generating random data.
Ferdinando Pasqualetti schrieb:
> I think you should use /dev/random, not /dev/zero unless hardware
> compression is disabled in order to have more realistic figures.
This wouldn't be a good idea, /dev/random or /dev/urandom are just too
slow in generating random data. To test the nativ speed of
23 matches
Mail list logo
