Thank you everyone for your help!
Oracle replaced the drive and while it's not running with as high a
throughput as I would like, it's at least up at the 60MB/s (random data)
that my other drives are at, rather than it's previous 30MB/s.
I'm still going to experiment with some of the ideas
On 02/10/12 01:35, Stephen Thompson wrote:
Correction, the non-problem drive has a higher ECC fast error count,
but the problem drive has a significantly higher Corrective algorithm
invocations count.
What that means is that it rewrote the data, which accounts for the
lower throughput.
Alan Brown wrote (2012/10/01):
2Mb is the maximum block size I've found to work on LTO* - it's a bacula
limit, not an LTO one.
Or it could be a limit of an operating system or of used hw interface.
Increasing from 65535 will improve throughput significantly.
There have been discussions
Hi,
I ran some btape tests today to verify that I'd be improving throughput
by changing blocksize from 256KB to 2MB and found that this does indeed
appear to be true in terms of increasing compression efficiency, but it
doesn't seem to affect incompressible data much, if at all. Still, it
Hi,
I ran some btape tests today to verify that I'd be improving throughput by
changing blocksize from 256KB to 2MB and found that this does indeed
appear to be true in terms of increasing compression efficiency, but it
doesn't seem to affect incompressible data much, if at all. Still,
On 10/01/2012 03:52 PM, James Harper wrote:
Hi,
I ran some btape tests today to verify that I'd be improving throughput by
changing blocksize from 256KB to 2MB and found that this does indeed
appear to be true in terms of increasing compression efficiency, but it
doesn't seem to affect
On 01/10/12 23:38, Stephen Thompson wrote:
More importantly, I realized that my testing 6 months ago was not on
all 4 of my drives, but only 2 of them. Today, I discovered one of my
drives (untested in the past) is getting 1/2 the throughput for random
data writes as the others!!
On 10/1/12 4:06 PM, Alan Brown wrote:
On 01/10/12 23:38, Stephen Thompson wrote:
More importantly, I realized that my testing 6 months ago was not on
all 4 of my drives, but only 2 of them. Today, I discovered one of my
drives (untested in the past) is getting 1/2 the throughput for random
Correction, the non-problem drive has a higher ECC fast error count,
but the problem drive has a significantly higher Corrective algorithm
invocations count.
On 10/1/12 5:33 PM, Stephen Thompson wrote:
On 10/1/12 4:06 PM, Alan Brown wrote:
On 01/10/12 23:38, Stephen Thompson wrote:
Alan Brown wrote (2012/09/28):
Aren't these considered reasonable settings for LTO3?
Maximum block size = 262144 # 256kb
Maximum File Size = 2gb
Not really.
Hi, I have
Maximum Block Size = 65536
Maximum File Size = 4gb
and without any problem. All tapes have
On 30/09/12 22:42, Cejka Rudolf wrote:
Hi, I have Maximum Block Size = 65536 Maximum File Size = 4gb and
without any problem. All tapes have over 400,000,000,000 bytes, except
2 of 116, where I think that one was forced to change, so just 1 of
116 has under 400 GB (around 380 GB). Almost
On 28/09/12 02:38, Stephen Thompson wrote:
Aren't these considered reasonable settings for LTO3?
Maximum block size = 262144 # 256kb
Maximum File Size = 2gb
Not really.
Change maximum file size to 10Gb and maximum block size to 2M
You _must_ set all open tapes to used and
On 26/09/12 22:37, Stephen Thompson wrote:
I think I pointed this out before, but I also have used and new tapes
with 400-800Gb on them. It seems really hit or miss, though the tapes
with 400Gb or less are probably a 1/3 of my tapes. The other 2/3 have
above 400Gb.
If you have small
On 09/25/2012 10:43 AM, Alan Brown wrote:
On 25/09/12 17:43, Stephen Thompson wrote:
Our Sun/Oracle service engineer claims that our drives do not require
cleaning tapes. Does that sound legit?
In general: true (as in, Don't do it as a scheduled item), but all LTO
drives require cleaning
On 27/09/12 22:25, Stephen Thompson wrote:
What happens if you mark the volumes as append and put them back in
the library?
I haven't had a lot of time to look into this today, but I do this
quick test and it immediately marks the volume Full again.
Then it really is full and the rest is
On 9/27/12 6:17 PM, Alan Brown wrote:
On 27/09/12 22:25, Stephen Thompson wrote:
What happens if you mark the volumes as append and put them back in
the library?
I haven't had a lot of time to look into this today, but I do this
quick test and it immediately marks the volume Full again.
On 09/25/2012 02:29 PM, Cejka Rudolf wrote:
Stephen Thompson wrote (2012/09/25):
The tape in question have only been used once or twice.
Do you mean just one or two drive loads and unloads?
Yes, I mean the tapes have only been in a drive once or twice, possibly
for a dozen sequential jobs
On 09/26/2012 02:35 PM, Stephen Thompson wrote:
On 09/25/2012 02:29 PM, Cejka Rudolf wrote:
Stephen Thompson wrote (2012/09/25):
The tape in question have only been used once or twice.
Do you mean just one or two drive loads and unloads?
Yes, I mean the tapes have only been in a drive once
Zitat von Stephen Thompson step...@seismo.berkeley.edu:
Thanks for the info, John.
Is there anyone else in the bacula community with LTO3's seeing this
behaviour? I don't believe (but am not 100% sure) that I'm having any
hardware-related issues.
Not sure what to make of this. About 25%
Op 25/09/2012 2:03, James Harper schreef:
Hello all,
This is not likely a bacula questions, but in the chance that it is, or the
experience on this list, I figured I would ask.
We've been using LTO3 tapes with bacula for a few years now. Recently I've
noticed how variable our tape capacity
On 25/09/12 09:08, Jeremy Maes wrote:
The tape and/or drive should record the margin and other figures, but I don't
know of any Linux tools to read that information.
The tools depend on the brand. For HP drives ltt is nice and works
flawlessly on linux command-line. It reports drive errors,
We've been using LTO3 tapes with bacula for a few years now. Recently I've
noticed how variable our tape capacity it, ranging from 200-800 Gb.
Is that strictly governed by the compressibility of the actual data being
backed up?
Hello,
the lower bound 200 GB on 400 GB LTO-3 tapes is
Thanks everyone for the suggestions, they at least give me somewhere to
look, as I was running low on ideas.
More info...
The tape in question have only been used once or twice.
The library is a StorageTek whose SLConsole reports no media (or drive)
errors, though I will look into those
On 25/09/12 17:43, Stephen Thompson wrote:
Our Sun/Oracle service engineer claims that our drives do not require
cleaning tapes. Does that sound legit?
In general: true (as in, Don't do it as a scheduled item), but all LTO
drives require cleaning tapes from time to time and sometimes benefit
On 9/25/12 12:43 PM, Stephen Thompson step...@seismo.berkeley.edu
wrote:
Thanks everyone for the suggestions, they at least give me somewhere to
look, as I was running low on ideas.
More info...
The tape in question have only been used once or twice.
The library is a StorageTek whose
On 09/25/2012 10:43 AM, Alan Brown wrote:
On 25/09/12 17:43, Stephen Thompson wrote:
Our Sun/Oracle service engineer claims that our drives do not require
cleaning tapes. Does that sound legit?
In general: true (as in, Don't do it as a scheduled item), but all LTO
drives require cleaning
On 09/25/2012 11:17 AM, Konstantin Khomoutov wrote:
On Tue, 25 Sep 2012 11:00:07 -0700
Stephen Thompson step...@seismo.berkeley.edu wrote:
60Mb/s is _slow_ for LTO3. You need to take a serious look at what
you're using as stage disk and consider using a raid0 array of SSDs
in order to keep
Zitat von Stephen Thompson step...@seismo.berkeley.edu:
On 09/25/2012 10:43 AM, Alan Brown wrote:
On 25/09/12 17:43, Stephen Thompson wrote:
Our Sun/Oracle service engineer claims that our drives do not require
cleaning tapes. Does that sound legit?
In general: true (as in, Don't do it as
Stephen Thompson wrote (2012/09/25):
The tape in question have only been used once or twice.
Do you mean just one or two drive loads and unloads?
The library is a StorageTek whose SLConsole reports no media (or drive)
errors, though I will look into those linux-based tools.
There are
I've found LTO drives of any variety rarely need cleaning. I've found that
one
cleaning tape will usually be sufficient for the life of a library. Your
field
support may very well be right.
The drive has an internal cleaning mechanism that is activated on load
This is not likely a bacula questions, but in the chance that it is, or
the experience on this list, I figured I would ask.
We've been using LTO3 tapes with bacula for a few years now. Recently
I've noticed how variable our tape capacity it, ranging from 200-800 Gb.
Is that strictly
Thanks for the info, John.
Is there anyone else in the bacula community with LTO3's seeing this
behaviour? I don't believe (but am not 100% sure) that I'm having any
hardware-related issues.
Not sure what to make of this. About 25% of tapes in a monthly run (70
tapes) are under the 400Gb
Hello all,
This is not likely a bacula questions, but in the chance that it is, or the
experience on this list, I figured I would ask.
We've been using LTO3 tapes with bacula for a few years now. Recently I've
noticed how variable our tape capacity it, ranging from 200-800 Gb.
Is
33 matches
Mail list logo
