Sergio Belkin schrieb:
> The output test was:
>
> dd if=/dev/zero of=/dev/nst0 bs=1M count=1000
> 1000+0 records in
> 1000+0 records out
> 1048576000 bytes (1.0 GB) copied, 7.80926 seconds, 134 MB/s
This looks ok.
> Below is output of tapeinfo -f /dev/sg0
>
> Product Type: Disk Drive
But sg0
The output test was:
dd if=/dev/zero of=/dev/nst0 bs=1M count=1000
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 7.80926 seconds, 134 MB/s
I have a server let say A that has director and storage daemon with a
DAT72 and other server say B which has storage daemon and a LTO
Jason A. Kates wrote:
> For a speed test /dev/zero isn't the best item to use as the hardware
> compression will show how good it can be. I would test on files that
> aren't in the OS cache and will have representative level of
> compression.
I agree, but if the test with /dev/zero ends with 10M
For a speed test /dev/zero isn't the best item to use as the hardware
compression will show how good it can be. I would test on files that
aren't in the OS cache and will have representative level of
compression.
-Jason
On Fri, 2009-01-02 at 20:14 +0100, Jesper Kr
> I have an IBM Type 8765-1UXD LTO3, is working but not at its best performance.
> As wikipedia its Max Speed (MB/s) should be Max Speed 80 MB/s and the
> actual is about 10 Mb/s.
>
Is this over a network? If so is the network Gbit? Are you talking
about an incremental backup or full? Is your datab
Sergio Belkin wrote:
> Hi,
>
> I have an IBM Type 8765-1UXD LTO3, is working but not at its best performance.
> As wikipedia its Max Speed (MB/s) should be Max Speed 80 MB/s and the
> actual is about 10 Mb/s.
>
> Could be some miscofiguration of bacula? What can I twak? I tried not
> using compre
On Tuesday 21 February 2006 15:44, Rudolf Cejka wrote:
> Kern Sibbald wrote (2006/02/21):
> > > One thread would read data and compute md5, the second thread would
> > > just try to write data to the tape.
> >
> > This is already the case. Reading the data and computing the md5 sum is
> > done in t
Kern Sibbald wrote (2006/02/21):
> > One thread would read data and compute md5, the second thread would
> > just try to write data to the tape.
> This is already the case. Reading the data and computing the md5 sum is done
> in the FD, writing the data is done in the SD. Not only are they separat
On Thursday 16 February 2006 12:25, Rudolf Cejka wrote:
> Keith Brautigam wrote (2006/02/15):
> > Quinton Jansen wrote:
> > >What speeds are others getting when using an LTO-3 drive?
>
> I take up interest just in direct writing speed to the tape reported
> by iostat, which I have typically about 6
Rudolf Cejka wrote:
Keith Brautigam wrote (2006/02/16):
What actual speed are you getting now during the de-spooling process?
Typically 60 - 80 MB/s (note that file boundaries on tapes temporarily
slows down the speed), however now my backup is idle, so I could not
see it right now
Keith Brautigam wrote (2006/02/16):
> What actual speed are you getting now during the de-spooling process?
Typically 60 - 80 MB/s (note that file boundaries on tapes temporarily
slows down the speed), however now my backup is idle, so I could not
see it right now.
> Also, how would you recomme
Gregory Orange wrote:
[EMAIL PROTECTED] wrote:
I have a few questions about your bakups. Is there a thousands of
small files? Do
you have compression set or a signiture in the file set resource? Are
you using data
spooling? Is the database on the same machine as the bacula server?
What version
[EMAIL PROTECTED] wrote:
I have a few questions about your bakups. Is there a thousands of small files?
Do
you have compression set or a signiture in the file set resource? Are you using
data
spooling? Is the database on the same machine as the bacula server? What
version of
bacula are you usi
Rudolf Cejka wrote:
Keith Brautigam wrote (2006/02/15):
Quinton Jansen wrote:
What speeds are others getting when using an LTO-3 drive?
I take up interest just in direct writing speed to the tape reported
by iostat, which I have typically about 60-80 MB/s, but still I think
Many thanks for all your feedback.
After spending 90 minutes redoing the same debugging with two different
people, Quantum decided to send a replacement unit. Hopefully that will be
here today.
Thank for your configuration feedback. I do appreciate it.
Quinton
On February 16, 2006 03:25, Ru
Now this _is_ a little off-topic, going from the subject line, but...
On 2/16/2006 4:00 PM, [EMAIL PROTECTED] wrote:
... I recently got into an argument where I work
(hospital environment) where the person incharge of network planning said that
they
have done benchmarks and gigabit does not inp
I have a few questions about your bakups. Is there a thousands of small files?
Do
you have compression set or a signiture in the file set resource? Are you using
data
spooling? Is the database on the same machine as the bacula server? What
version of
bacula are you using? Sorry if you answered
> Indeed. However even for those hosts that do have 100Mb somewhere
> between them and the tape drive, one might expect better than 3.5MB/s -
> as I said, with some tweaking.
>
> Another speed factor we've noticed (which has possibly been discussed ad
> nauseum elsewhere on this list) is that o
Keith Brautigam wrote (2006/02/15):
> Quinton Jansen wrote:
> >What speeds are others getting when using an LTO-3 drive?
I take up interest just in direct writing speed to the tape reported
by iostat, which I have typically about 60-80 MB/s, but still I think
that it should be better, because 80 M
[EMAIL PROTECTED] wrote:
Yes over a network except the fastest one (where all of our data lies),
mostly over gigabit. The two slowest hosts are due for retirement in the
next few months.
Greg.
Without 100% gigbit (no 100MBit links/switches routers...) or better between the
bacula server and th
> Yes over a network except the fastest one (where all of our data lies),
> mostly over gigabit. The two slowest hosts are due for retirement in the
> next few months.
> Greg.
Without 100% gigbit (no 100MBit links/switches routers...) or better between the
bacula server and the data you will not
[EMAIL PROTECTED] wrote:
We've got a HP DL/585, looks like same drive, dedicated SCSI-attached.
The lowest rate I saw on our simple btape fill was 58MB/sec. As for real
backup rates, various hosts give different speeds. With all four hosts
running 1.38.3 compiled from source, our most recent fu
> We've got a HP DL/585, looks like same drive, dedicated SCSI-attached.
> The lowest rate I saw on our simple btape fill was 58MB/sec. As for real
> backup rates, various hosts give different speeds. With all four hosts
> running 1.38.3 compiled from source, our most recent full backups gave
>
Quinton Jansen wrote:
What speeds are others getting when using an LTO-3 drive?
If I'm reading the numbers correctly, 2GB in 13 minutes (10GB/hour) is way too
slow (should be around 200G/hour).
I've got a brand new Quantum Superloader-3, LTO3 attached to a dedicated SCSI
bus on a HP DL/380,
Quinton Jansen wrote:
What speeds are others getting when using an LTO-3 drive?
If I'm reading the numbers correctly, 2GB in 13 minutes (10GB/hour) is way too
slow (should be around 200G/hour).
I've got a brand new Quantum Superloader-3, LTO3 attached to a dedicated SCSI
bus on a HP DL/380,
25 matches
Mail list logo
