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:
>>>
>>> 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
|
