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 that were tossed
out and see if I can't get even better throughput of for bacula.
thanks again,
Stephen
On 10/2/12 2:47 AM, Alan Brown wrote:
> 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.
>
> LTO drives read as they write and if there are errors, they write again.
>
> If a cleaning tape doesn't work then you need to get the drive looked
> at/replaced under warranty.
>
>
>> 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:
>>>>> 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!!
>>>> "smartctl -a /dev/sg(drive)" will tell you a lot
>>>>
>>>> Put a cleaning tape in it....
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> Cleaning tape did not improve results.
>>>
>>> I see some errors in the counter log on the problem drive, but I see
>>> even more errors on another drive which isn't having a throughput
>>> problem (specifically SL500 Drive 1 is the lower throughput, but C4
>>> Drive 1 actually has a higher error count).
>>>
>>>
>>>
>>> SL500 Drive 0 (~60MB/s random data throughput)
>>> =============
>>> Error counter log:
>>> Errors Corrected by Total Correction
>>> Gigabytes Total
>>> ECC rereads/ errors algorithm
>>> processed uncorrected
>>> fast | delayed rewrites corrected invocations [10^9
>>> bytes] errors
>>> read: 0 0 0 0 0 0.000
>>> 0
>>> write: 0 0 0 0 0 0.000
>>> 0
>>>
>>>
>>> SL500 Drive 1 (~30MB/s random data throughput)
>>> =============
>>> Error counter log:
>>> Errors Corrected by Total Correction
>>> Gigabytes Total
>>> ECC rereads/ errors algorithm
>>> processed uncorrected
>>> fast | delayed rewrites corrected invocations [10^9
>>> bytes] errors
>>> read: 0 0 0 0 0 0.000
>>> 0
>>> write: 10454 0 0 0 821389 0.000
>>> 0
>>>
>>>
>>> C4 Drive 0 (~60MB/s random data throughput)
>>> ==========
>>> Error counter log:
>>> Errors Corrected by Total Correction
>>> Gigabytes Total
>>> ECC rereads/ errors algorithm
>>> processed uncorrected
>>> fast | delayed rewrites corrected invocations [10^9
>>> bytes] errors
>>> read: 2 0 0 0 2 0.000
>>> 0
>>> write: 0 0 0 0 0 0.000
>>> 0
>>>
>>>
>>> C4 Drive 1 (~60MB/s random data throughput)
>>> ==========
>>> Error counter log:
>>> Errors Corrected by Total Correction
>>> Gigabytes Total
>>> ECC rereads/ errors algorithm
>>> processed uncorrected
>>> fast | delayed rewrites corrected invocations [10^9
>>> bytes] errors
>>> read: 2 0 0 0 2 0.000
>>> 0
>>> write: 18961 0 0 0 48261 0.000
>>> 0
>>>
>>>
>>>
>>>
>>> Stephen
>>>
>
>
--
Stephen Thompson Berkeley Seismological Laboratory
stephen AT seismo.berkeley DOT edu 215 McCone Hall # 4760
404.538.7077 (phone) University of California, Berkeley
510.643.5811 (fax) Berkeley, CA 94720-4760
------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
