RAID6 data-check took almost 2 hours, clicking sounds, system unresponsive

Hi Neil,

My original email may have been eaten: as it did not appear on the list, nor did I get an error message back. So perhaps there was a problem with the attached files.

I will resend the attachments one at a time in separate emails.


Cheers,
Gavin

[begin original]
Hi Neil,

Your help (or anybody else's) would be greatly appreciated, yet again!

This morning, I noticed my system was extremely unresponsive, and that there were clicking sounds coming from one of my 5 hard drives. Also that there was excessive disk I/O even for trivial things like bring up a directory window, and lots of ata3 errors being reported to the system log. These symptoms were mostly during a raid check process.

Somewhere along the way, I seemed to have lost my swap partition!

So I did some extensive investigations, which took most of the day. My notes were created in OpenDocument format using LibreOffice, but I have converted them to txt format for the include - but I can supply the ,odt file if requested.

I Have included 2 files:
my notes: raid-notes-20110407a.txt
selected log entries: messages-gcf-20110407-ATA

If there are some additional diagnostics that might prove useful, please let me know.


Cheers,
Gavin
[end original]
--
All Adults share the Responsibility
to help Raise Today's Children,
for they are Tomorrow's Society!
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: RAID6 data-check took almost 2 hours, clicking sounds, system unresponsive

--0-1335622535-1302226463=:10299
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

my notes: raid-notes-20110407a.txt=0A--=0AAll Adults share the Responsibili=
ty=0Ato help Raise Today's Children,=0Afor they are Tomorrow's Society!=0A=
--- On Fri, 8/4/11, Gavin Flower wrote: =
> From: Gavin Flower =0A> Subject: RAID6 data-check =
took almost 2 hours, clicking sounds, system unresponsive=0A> To: neilb@sus=
e.de=0A> Cc: linux-raid@vger.kernel.org=0A> Date: Friday, 8 April, 2011, 13=
:32=0A[...]
--0-1335622535-1302226463=:10299
Content-Type: text/plain; name="raid-notes-20110407a.txt"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="raid-notes-20110407a.txt"

77u/Tm90ZSB0aGF0IHRoZSBjaGVjayBvbiBtZDEgdG9vayBhbG1vc3QgMiBo
b3VycyEKIyBncmVwIG1kMSAvdmFyL2xvZy9tZXNzYWdlcyAKQXByICA0IDA4
OjI1OjM4IHNhdHVybiBrZXJuZWw6IFsgICAgMy4yMDMwNThdIG1kOiBtZDEg
c3RvcHBlZC4gCkFwciAgNCAwODoyNTozOCBzYXR1cm4ga2VybmVsOiBbICAg
IDMuMjIxODIxXSBtZC9yYWlkOm1kMTogZGV2aWNlIHNkYTIgb3BlcmF0aW9u
YWwgYXMgcmFpZCBkaXNrIDAgCkFwciAgNCAwODoyNTozOCBzYXR1cm4ga2Vy
bmVsOiBbICAgIDMuMjIzMDk5XSBtZC9yYWlkOm1kMTogZGV2aWNlIHNkYzIg
b3BlcmF0aW9uYWwgYXMgcmFpZCBkaXNrIDQgCkFwciAgNCAwODoyNTozOCBz
YXR1cm4ga2VybmVsOiBbICAgIDMuMjI0MzY0XSBtZC9yYWlkOm1kMTogZGV2
aWNlIHNkZDIgb3BlcmF0aW9uYWwgYXMgcmFpZCBkaXNrIDMgCkFwciAgNCAw
ODoyNTozOCBzYXR1cm4ga2VybmVsOiBbICAgIDMuMjI1NTg5XSBtZC9yYWlk
Om1kMTogZGV2aWNlIHNkZTIgb3BlcmF0aW9uYWwgYXMgcmFpZCBkaXNrIDIg
CkFwciAgNCAwODoyNTozOCBzYXR1cm4ga2VybmVsOiBbICAgIDMuMjI2ODA2
XSBtZC9yYWlkOm1kMTogZGV2aWNlIHNkYjIgb3BlcmF0aW9uYWwgYXMgcmFp
ZCBkaXNrIDEgCkFwciAgNCAwODoyNTozOCBzYXR1cm4ga2VybmVsOiBbICAg
IDMuMjI5MjU2XSBtZC9yYWlkOm1kMTogYWxsb2NhdGVkIDUzMzRrQiAKQXBy
ICA0IDA4OjI1OjM4IHNhdHVybiBrZXJuZWw6IFsgICAgMy4yMzA1MDBdIG1k
L3JhaWQ6bWQxOiByYWlkIGxldmVsIDYgYWN0aXZlIHdpdGggNSBvdXQgb2Yg
NSBkZXZpY2VzLCBhbGdvcml0aG0gMiAKQXByICA0IDA4OjI1OjM4IHNhdHVy
biBrZXJuZWw6IFsgICAgMy4yMzI1MDNdIG1kMTogZGV0ZWN0ZWQgY2FwYWNp
dHkgY2hhbmdlIGZyb20gMCB0byAzMTQ1NzEyMjcxMzYgCkFwciAgNCAwODoy
NTozOCBzYXR1cm4ga2VybmVsOiBbICAgIDMuMjM0NTU5XSBkcmFjdXQ6IG1k
YWRtOiAvZGV2L21kMSBoYXMgYmVlbiBzdGFydGVkIHdpdGggNSBkcml2ZXMu
IApBcHIgIDQgMDg6MjU6Mzggc2F0dXJuIGtlcm5lbDogWyAgICAzLjIzNjI1
N10gbWQxOiBkZXRlY3RlZCBjYXBhY2l0eSBjaGFuZ2UgZnJvbSAwIHRvIDMx
NDU3MTIyNzEzNiAKQXByICA0IDA4OjI1OjM4IHNhdHVybiBrZXJuZWw6IFsg
ICAgMy4yMzc0MjVdICBtZDE6IHVua25vd24gcGFydGl0aW9uIHRhYmxlIApB
cHIgIDQgMDg6MjU6Mzggc2F0dXJuIGtlcm5lbDogWyAgICA5Ljg5MjA2OF0g
RVhUNC1mcyAobWQxKTogbW91bnRlZCBmaWxlc3lzdGVtIHdpdGggb3JkZXJl
ZCBkYXRhIG1vZGUuIE9wdHM6IChudWxsKSAKQXByICA1IDA3OjA1OjI4IHNh
dHVybiBrZXJuZWw6IFs2NTM1Ni45MjYwNzldIE1vZHVsZXMgbGlua2VkIGlu
OiB0Y3BfbHAgcG93ZXJub3dfazggZnJlcV90YWJsZSBtcGVyZiBmdXNlIGVi
dGFibGVfbmF0IGVidGFibGVzIGlwdF9NQVNRVUVSQURFIGlwdGFibGVfbmF0
IG5mX25hdCB4dF9UQ1BNU1MgaXB0X0xPRyB4dF9saW1pdCBicmlkZ2Ugc3Rw
IGxsYyBybWQxNjAgY3J5cHRvX251bGwgY2FtZWxsaWEgbHpvIGx6b19jb21w
cmVzcyBjYXN0NiBjYXN0NSBkZWZsYXRlIHpsaWJfZGVmbGF0ZSBjdHMgY3Ry
IGdjbSBjY20gc2VycGVudCBibG93ZmlzaCB0d29maXNoX3g4Nl82NCB0d29m
aXNoX2NvbW1vbiBlY2IgeGNiYyBjYmMgc2hhMjU2X2dlbmVyaWMgc2hhNTEy
X2dlbmVyaWMgZGVzX2dlbmVyaWMgY3J5cHRkIGFlc194ODZfNjQgYWVzX2dl
bmVyaWMgYWg2IGFoNCBlc3A2IGVzcDQgeGZybTRfbW9kZV9iZWV0IHhmcm00
X3R1bm5lbCB0dW5uZWw0IHhmcm00X21vZGVfdHVubmVsIHhmcm00X21vZGVf
dHJhbnNwb3J0IHhmcm02X21vZGVfdHJhbnNwb3J0IHhmcm02X21vZGVfcm8g
eGZybTZfbW9kZV9iZWV0IHhmcm02X21vZGVfdHVubmVsIGlwY29tcCBpcGNv
bXA2IHhmcm1faXBjb21wIHhmcm02X3R1bm5lbCB0dW5uZWw2IGFmX2tleSBi
bHVldG9vdGggcmZraWxsIG5mc2QgbG9ja2QgbmZzX2FjbCBhdXRoX3JwY2dz
cyBleHBvcnRmcyBzdW5ycGMgaXA2dF9SRUpFQ1QgbmZfY29ubnRyYWNrX2lw
djYgaXA2dGFibGVfZmlsdGVyIGlwNl90YWJsZXMgaXB2NiBrdm1fYW1kIGt2
bSB1c2JscCByODE2OSBlZGFjX2NvcmUgYXRsMWUgdXZjdmlkZW8gbWlpIHNu
ZF9oZGFfY29kZWNfYXRpaGRtaSBlZGFjX21jZV9hbWQgc2hwY2hwIHZpZGVv
ZGV2IHY0bDJfY29tcGF0X2lvY3RsMzIgYXN1c19hdGswMTEwIHNlcmlvX3Jh
dyBzbmRfaGRhX2NvZGVjX3ZpYSBzbmRfdXNiX2F1ZGlvIHNuZF91c2JtaWRp
X2xpYiBqb3lkZXYgc25kX2hkYV9pbnRlbCBpMmNfcGlpeDQgazEwdGVtcCBz
bmRfaGRhX2NvZGVjIHNuZF9odyAKQXByICA3IDA3OjU0OjAxIHNhdHVybiBr
ZXJuZWw6IFsyMDc1NDYuMTg4ODAwXSBtZDogZGF0YS1jaGVjayBvZiBSQUlE
IGFycmF5IG1kMSAKQXByICA3IDA3OjU0OjAxIHNhdHVybiBrZXJuZWw6IFsy
MDc1NDYuMTg4ODY4XSBtZDogZGVsYXlpbmcgZGF0YS1jaGVjayBvZiBtZDAg
dW50aWwgbWQxIGhhcyBmaW5pc2hlZCAodGhleSBzaGFyZSBvbmUgb3IgbW9y
ZSBwaHlzaWNhbCB1bml0cykgCkFwciAgNyAwNzo1NDowMSBzYXR1cm4ga2Vy
bmVsOiBbMjA3NTQ2LjE5MDUxN10gbWQ6IGRlbGF5aW5nIGRhdGEtY2hlY2sg
b2YgbWQyIHVudGlsIG1kMSBoYXMgZmluaXNoZWQgKHRoZXkgc2hhcmUgb25l
IG9yIG1vcmUgcGh5c2ljYWwgdW5pdHMpIApBcHIgIDcgMDc6NTQ6MDEgc2F0
dXJuIGtlcm5lbDogWzIwNzU0Ni4xOTA1MjNdIG1kOiBkZWxheWluZyBkYXRh
LWNoZWNrIG9mIG1kMCB1bnRpbCBtZDEgaGFzIGZpbmlzaGVkICh0aGV5IHNo
YXJlIG9uZSBvciBtb3JlIHBoeXNpY2FsIHVuaXRzKSAKQXByICA3IDA4OjQy
OjA4IHNhdHVybiBrZXJuZWw6IFsyMTA0MTQuMTA5ODU2XSBtZC9yYWlkOm1k
MTogcmVhZCBlcnJvciBjb3JyZWN0ZWQgKDggc2VjdG9ycyBhdCAxNzE5NTgw
MCBvbiBzZGMyKSAKQXByICA3IDA4OjQyOjA4IHNhdHVybiBrZXJuZWw6IFsy
MTA0MTQuMTA5ODY5XSBtZC9yYWlkOm1kMTogcmVhZCBlcnJvciBjb3JyZWN0
ZWQgKDggc2VjdG9ycyBhdCAxNzE5NTgwOCBvbiBzZGMyKSAKQXByICA3IDA4
OjQyOjA4IHNhdHVybiBrZXJuZWw6IFsyMTA0MTQuMTA5ODcyXSBtZC9yYWlk
Om1kMTogcmVhZCBlcnJvciBjb3JyZWN0ZWQgKDggc2VjdG9ycyBhdCAxNzE5
NTgxNiBvbiBzZGMyKSAKQXByICA3IDA4OjQyOjA4IHNhdHVybiBrZXJuZWw6
IFsyMTA0MTQuMTA5ODc1XSBtZC9yYWlkOm1kMTogcmVhZCBlcnJvciBjb3Jy
ZWN0ZWQgKDggc2VjdG9ycyBhdCAxNzE5NTgyNCBvbiBzZGMyKSAKQXByICA3
IDA4OjQyOjA4IHNhdHVybiBrZXJuZWw6IFsyMTA0MTQuMTA5ODc3XSBtZC9y
YWlkOm1kMTogcmVhZCBlcnJvciBjb3JyZWN0ZWQgKDggc2VjdG9ycyBhdCAx
NzE5NTgzMiBvbiBzZGMyKSAKQXByICA3IDA4OjQyOjA4IHNhdHVybiBrZXJu
ZWw6IFsyMTA0MTQuMTA5ODgwXSBtZC9yYWlkOm1kMTogcmVhZCBlcnJvciBj
b3JyZWN0ZWQgKDggc2VjdG9ycyBhdCAxNzE5NTg0MCBvbiBzZGMyKSAKQXBy
ICA3IDA4OjQyOjA4IHNhdHVybiBrZXJuZWw6IFsyMTA0MTQuMTA5ODgzXSBt
ZC9yYWlkOm1kMTogcmVhZCBlcnJvciBjb3JyZWN0ZWQgKDggc2VjdG9ycyBh
dCAxNzE5NTg0OCBvbiBzZGMyKSAKQXByICA3IDA4OjQyOjA4IHNhdHVybiBr
ZXJuZWw6IFsyMTA0MTQuMTA5ODkxXSBtZC9yYWlkOm1kMTogcmVhZCBlcnJv
ciBjb3JyZWN0ZWQgKDggc2VjdG9ycyBhdCAxNzE5NTg1NiBvbiBzZGMyKSAK
QXByICA3IDA4OjQyOjA4IHNhdHVybiBrZXJuZWw6IFsyMTA0MTQuMTA5ODk0
XSBtZC9yYWlkOm1kMTogcmVhZCBlcnJvciBjb3JyZWN0ZWQgKDggc2VjdG9y
cyBhdCAxNzE5NTg2NCBvbiBzZGMyKSAKQXByICA3IDA4OjQyOjA4IHNhdHVy
biBrZXJuZWw6IFsyMTA0MTQuMTA5ODk3XSBtZC9yYWlkOm1kMTogcmVhZCBl
cnJvciBjb3JyZWN0ZWQgKDggc2VjdG9ycyBhdCAxNzE5NTg3MiBvbiBzZGMy
KSAKQXByICA3IDA4OjU0OjM5IHNhdHVybiBrZXJuZWw6IFsyMTExNjEuODI0
MDY2XSBtZC9yYWlkOm1kMTogcmVhZCBlcnJvciBjb3JyZWN0ZWQgKDggc2Vj
dG9ycyBhdCAxMzcwMTQ1Mjggb24gc2RjMikgCkFwciAgNyAwOTo1MTo0NyBz
YXR1cm4ga2VybmVsOiBbMjE0NTgxLjE0MDU2MF0gbWQ6IG1kMTogZGF0YS1j
aGVjayBkb25lLiAKIyAKCiMgZGF0ZSA7IGNhdCAvcHJvYy9tZHN0YXQgClRo
dSBBcHIgIDcgMTA6MzE6MjQgTlpTVCAyMDExIApQZXJzb25hbGl0aWVzIDog
W3JhaWQ2XSBbcmFpZDVdIFtyYWlkNF0gCm1kMiA6IGFjdGl2ZSByYWlkNiBz
ZGE0WzBdIHNkYzRbNl0gc2RkNFszXSBzZGI0WzVdIHNkZTRbMV0gCiAgICAg
IDExMTQ3NDU4NTYgYmxvY2tzIHN1cGVyIDEuMSBsZXZlbCA2LCA1MTJrIGNo
dW5rLCBhbGdvcml0aG0gMiBbNS81XSBbVVVVVVVdIAogICAgICBbPT09PT09
PT09PT4uLi4uLi4uLi4uXSAgY2hlY2sgPSA1NC4xJSAoMjAxMDY4NDE2LzM3
MTU4MTk1MikgZmluaXNoPTMyLjZtaW4gc3BlZWQ9ODcxMjlLL3NlYyAKICAg
ICAgYml0bWFwOiAyLzMgcGFnZXMgWzhLQl0sIDY1NTM2S0IgY2h1bmsgCgpt
ZDEgOiBhY3RpdmUgcmFpZDYgc2RhMlswXSBzZGMyWzRdIHNkZDJbM10gc2Rl
MlsyXSBzZGIyWzFdIAogICAgICAzMDcxOTg0NjQgYmxvY2tzIGxldmVsIDYs
IDUxMmsgY2h1bmssIGFsZ29yaXRobSAyIFs1LzVdIFtVVVVVVV0gCiAgICAg
IAptZDAgOiBhY3RpdmUgcmFpZDYgc2RhM1swXSBzZGIzWzRdIHNkZDNbM10g
c2RjM1syXSBzZGUzWzFdIAogICAgICAxMDc1MTgwOCBibG9ja3MgbGV2ZWwg
NiwgNjRrIGNodW5rLCBhbGdvcml0aG0gMiBbNS81XSBbVVVVVVVdIAogICAg
ICAKdW51c2VkIGRldmljZXM6IDxub25lPiAKIyAKCkZyb20gcm9vdEBsb2Nh
bGhvc3Q2LmxvY2FsZG9tYWluNiAgVGh1IEFwciAgNyAxMToxMjo0MSAyMDEx
IApSZXR1cm4tUGF0aDogPHJvb3RAbG9jYWxob3N0Ni5sb2NhbGRvbWFpbjY+
IApEYXRlOiBUaHUsIDcgQXByIDIwMTEgMTE6MTI6NDAgKzEyMDAgCkZyb206
IEFuYWNyb24gPHJvb3RAbG9jYWxob3N0Ni5sb2NhbGRvbWFpbjY+IApUbzog
cm9vdEBsb2NhbGhvc3Q2LmxvY2FsZG9tYWluNiAKQ29udGVudC1UeXBlOiB0
ZXh0L3BsYWluOyBjaGFyc2V0PSJBTlNJX1gzLjQtMTk2OCIgClN1YmplY3Q6
IEFuYWNyb24gam9iICdjcm9uLndlZWtseScgb24gc2F0dXJuIApTdGF0dXM6
IFIgCgovZXRjL2Nyb24ud2Vla2x5Lzk5LXJhaWQtY2hlY2s6IAoKV0FSTklO
RzogbWlzbWF0Y2hfY250IGlzIG5vdCAwIG9uIC9kZXYvbWQyIApXQVJOSU5H
OiBtaXNtYXRjaF9jbnQgaXMgbm90IDAgb24gL2Rldi9tZDAgCgojIGNhdCAv
c3lzL2Jsb2NrL21kMC9tZC9taXNtYXRjaF9jbnQKMTI4IAojIGNhdCAvc3lz
L2Jsb2NrL21kMS9tZC9taXNtYXRjaF9jbnQgCjAgCiMgY2F0IC9zeXMvYmxv
Y2svbWQyL21kL21pc21hdGNoX2NudCAKMjg5MDQgCiMgCgoKIyBlMmZzY2sg
LWYgLW4gL2Rldi9tZDIgCmUyZnNjayAxLjQxLjEyICgxNy1NYXktMjAxMCkg
Cldhcm5pbmchICAvZGV2L21kMiBpcyBtb3VudGVkLiAKV2FybmluZzogc2tp
cHBpbmcgam91cm5hbCByZWNvdmVyeSBiZWNhdXNlIGRvaW5nIGEgcmVhZC1v
bmx5IGZpbGVzeXN0ZW0gY2hlY2suIApQYXNzIDE6IENoZWNraW5nIGlub2Rl
cywgYmxvY2tzLCBhbmQgc2l6ZXMgCklub2RlcyB0aGF0IHdlcmUgcGFydCBv
ZiBhIGNvcnJ1cHRlZCBvcnBoYW4gbGlua2VkIGxpc3QgZm91bmQuICBGaXg/
IG5vIAoKSW5vZGUgMjAxODYzMzIgd2FzIHBhcnQgb2YgdGhlIG9ycGhhbmVk
IGlub2RlIGxpc3QuICBJR05PUkVELiAKSW5vZGUgMjAzMTc1MDYgd2FzIHBh
cnQgb2YgdGhlIG9ycGhhbmVkIGlub2RlIGxpc3QuICBJR05PUkVELiAKSW5v
ZGUgMjAzMTc1NTIgd2FzIHBhcnQgb2YgdGhlIG9ycGhhbmVkIGlub2RlIGxp
c3QuICBJR05PUkVELiAKSW5vZGUgMjAzMTc5NTUgd2FzIHBhcnQgb2YgdGhl
IG9ycGhhbmVkIGlub2RlIGxpc3QuICBJR05PUkVELiAKSW5vZGUgMjA0NDcy
Mzcgd2FzIHBhcnQgb2YgdGhlIG9ycGhhbmVkIGlub2RlIGxpc3QuICBJR05P
UkVELiAKSW5vZGUgMjA0NDcyNDUgd2FzIHBhcnQgb2YgdGhlIG9ycGhhbmVk
IGlub2RlIGxpc3QuICBJR05PUkVELiAKSW5vZGUgMjA0NDcyODcgd2FzIHBh
cnQgb2YgdGhlIG9ycGhhbmVkIGlub2RlIGxpc3QuICBJR05PUkVELiAKSW5v
ZGUgMjA0NDcyOTYgd2FzIHBhcnQgb2YgdGhlIG9ycGhhbmVkIGlub2RlIGxp
c3QuICBJR05PUkVELiAKSW5vZGUgMjA0NDczMDIgd2FzIHBhcnQgb2YgdGhl
IG9ycGhhbmVkIGlub2RlIGxpc3QuICBJR05PUkVELiAKSW5vZGUgMjA0NDcz
MTEgd2FzIHBhcnQgb2YgdGhlIG9ycGhhbmVkIGlub2RlIGxpc3QuICBJR05P
UkVELiAKSW5vZGUgMjA0NDczNTMgd2FzIHBhcnQgb2YgdGhlIG9ycGhhbmVk
IGlub2RlIGxpc3QuICBJR05PUkVELiAKSW5vZGUgMjA0NDczNjAgd2FzIHBh
cnQgb2YgdGhlIG9ycGhhbmVkIGlub2RlIGxpc3QuICBJR05PUkVELiAKSW5v
ZGUgMjE1MDA3ODcgd2FzIHBhcnQgb2YgdGhlIG9ycGhhbmVkIGlub2RlIGxp
c3QuICBJR05PUkVELiAKSW5vZGUgMjE2Mjg5MTMgd2FzIHBhcnQgb2YgdGhl
IG9ycGhhbmVkIGlub2RlIGxpc3QuICBJR05PUkVELiAKSW5vZGUgMjIxNTg4
MDggd2FzIHBhcnQgb2YgdGhlIG9ycGhhbmVkIGlub2RlIGxpc3QuICBJR05P
UkVELiAKSW5vZGUgMjIxNTg4MTEgd2FzIHBhcnQgb2YgdGhlIG9ycGhhbmVk
IGlub2RlIGxpc3QuICBJR05PUkVELiAKSW5vZGUgMjIxNTg4NDAgd2FzIHBh
cnQgb2YgdGhlIG9ycGhhbmVkIGlub2RlIGxpc3QuICBJR05PUkVELiAKSW5v
ZGUgMjIxNTg4NDIgd2FzIHBhcnQgb2YgdGhlIG9ycGhhbmVkIGlub2RlIGxp
c3QuICBJR05PUkVELiAKSW5vZGUgMjIxNTg4NDYgd2FzIHBhcnQgb2YgdGhl
IG9ycGhhbmVkIGlub2RlIGxpc3QuICBJR05PUkVELiAKSW5vZGUgMjU5NTI5
NDkgd2FzIHBhcnQgb2YgdGhlIG9ycGhhbmVkIGlub2RlIGxpc3QuICBJR05P
UkVELiAKSW5vZGUgMjU5NTM0MjQgd2FzIHBhcnQgb2YgdGhlIG9ycGhhbmVk
IGlub2RlIGxpc3QuICBJR05PUkVELiAKSW5vZGUgMjU5NTQ1NDIgd2FzIHBh
cnQgb2YgdGhlIG9ycGhhbmVkIGlub2RlIGxpc3QuICBJR05PUkVELiAKRGVs
ZXRlZCBpbm9kZSA0NTA4ODc3MSBoYXMgemVybyBkdGltZS4gIEZpeD8gbm8g
CgpJbm9kZSA0NTA4ODc3MiB3YXMgcGFydCBvZiB0aGUgb3JwaGFuZWQgaW5v
ZGUgbGlzdC4gIElHTk9SRUQuIApJbm9kZSA0NTA4ODc3MyB3YXMgcGFydCBv
ZiB0aGUgb3JwaGFuZWQgaW5vZGUgbGlzdC4gIElHTk9SRUQuIApJbm9kZSA0
NTA4ODc3NCB3YXMgcGFydCBvZiB0aGUgb3JwaGFuZWQgaW5vZGUgbGlzdC4g
IElHTk9SRUQuIApJbm9kZSA0NTA4ODc3NSB3YXMgcGFydCBvZiB0aGUgb3Jw
aGFuZWQgaW5vZGUgbGlzdC4gIElHTk9SRUQuIApJbm9kZSA0NTA4ODk3MiB3
YXMgcGFydCBvZiB0aGUgb3JwaGFuZWQgaW5vZGUgbGlzdC4gIElHTk9SRUQu
IApJbm9kZSA0NTA4OTAyMiB3YXMgcGFydCBvZiB0aGUgb3JwaGFuZWQgaW5v
ZGUgbGlzdC4gIElHTk9SRUQuIApJbm9kZSA0NTA4OTAzNSB3YXMgcGFydCBv
ZiB0aGUgb3JwaGFuZWQgaW5vZGUgbGlzdC4gIElHTk9SRUQuIApJbm9kZSA0
NTA4OTAzNyB3YXMgcGFydCBvZiB0aGUgb3JwaGFuZWQgaW5vZGUgbGlzdC4g
IElHTk9SRUQuIApJbm9kZSA0NTA4OTA0MyB3YXMgcGFydCBvZiB0aGUgb3Jw
aGFuZWQgaW5vZGUgbGlzdC4gIElHTk9SRUQuIApJbm9kZSA0NTA4OTA0NCB3
YXMgcGFydCBvZiB0aGUgb3JwaGFuZWQgaW5vZGUgbGlzdC4gIElHTk9SRUQu
IApJbm9kZSA0NTA4OTA0NSB3YXMgcGFydCBvZiB0aGUgb3JwaGFuZWQgaW5v
ZGUgbGlzdC4gIElHTk9SRUQuIApJbm9kZSA0NTA4OTA1NyB3YXMgcGFydCBv
ZiB0aGUgb3JwaGFuZWQgaW5vZGUgbGlzdC4gIElHTk9SRUQuIApJbm9kZSA0
NTA4OTA2MCB3YXMgcGFydCBvZiB0aGUgb3JwaGFuZWQgaW5vZGUgbGlzdC4g
IElHTk9SRUQuIApJbm9kZSA0NTA4OTA2MiB3YXMgcGFydCBvZiB0aGUgb3Jw
aGFuZWQgaW5vZGUgbGlzdC4gIElHTk9SRUQuIApJbm9kZSA0NTA4OTA2NCB3
YXMgcGFydCBvZiB0aGUgb3JwaGFuZWQgaW5vZGUgbGlzdC4gIElHTk9SRUQu
IApJbm9kZSA0NTA4OTA2NyB3YXMgcGFydCBvZiB0aGUgb3JwaGFuZWQgaW5v
ZGUgbGlzdC4gIElHTk9SRUQuIApJbm9kZSA0NTA4OTA2OCB3YXMgcGFydCBv
ZiB0aGUgb3JwaGFuZWQgaW5vZGUgbGlzdC4gIElHTk9SRUQuIApJbm9kZSA0
NTA4OTA3MCB3YXMgcGFydCBvZiB0aGUgb3JwaGFuZWQgaW5vZGUgbGlzdC4g
IElHTk9SRUQuIApJbm9kZSA0NTA4OTEzNyB3YXMgcGFydCBvZiB0aGUgb3Jw
aGFuZWQgaW5vZGUgbGlzdC4gIElHTk9SRUQuIApJbm9kZSA0NTA4OTE1MCB3
YXMgcGFydCBvZiB0aGUgb3JwaGFuZWQgaW5vZGUgbGlzdC4gIElHTk9SRUQu
IApJbm9kZSA0NTA4OTE1NiB3YXMgcGFydCBvZiB0aGUgb3JwaGFuZWQgaW5v
ZGUgbGlzdC4gIElHTk9SRUQuIApJbm9kZSA0NTA4OTE5MCB3YXMgcGFydCBv
ZiB0aGUgb3JwaGFuZWQgaW5vZGUgbGlzdC4gIElHTk9SRUQuIApJbm9kZSA0
NTA4OTIwNCB3YXMgcGFydCBvZiB0aGUgb3JwaGFuZWQgaW5vZGUgbGlzdC4g
IElHTk9SRUQuIApJbm9kZSA0NTA4OTIwNSB3YXMgcGFydCBvZiB0aGUgb3Jw
aGFuZWQgaW5vZGUgbGlzdC4gIElHTk9SRUQuIApJbm9kZSA0NTA4OTIwNyB3
YXMgcGFydCBvZiB0aGUgb3JwaGFuZWQgaW5vZGUgbGlzdC4gIElHTk9SRUQu
IApJbm9kZSA0NTA4OTIxMyB3YXMgcGFydCBvZiB0aGUgb3JwaGFuZWQgaW5v
ZGUgbGlzdC4gIElHTk9SRUQuIApJbm9kZSA0NTA4OTIxOCB3YXMgcGFydCBv
ZiB0aGUgb3JwaGFuZWQgaW5vZGUgbGlzdC4gIElHTk9SRUQuIApJbm9kZSA0
NTA4OTIzOCB3YXMgcGFydCBvZiB0aGUgb3JwaGFuZWQgaW5vZGUgbGlzdC4g
IElHTk9SRUQuIApJbm9kZSA0NTA4OTI0OSB3YXMgcGFydCBvZiB0aGUgb3Jw
aGFuZWQgaW5vZGUgbGlzdC4gIElHTk9SRUQuIApJbm9kZSA0NTA4OTI1NyB3
YXMgcGFydCBvZiB0aGUgb3JwaGFuZWQgaW5vZGUgbGlzdC4gIElHTk9SRUQu
IApJbm9kZSA0NTA4OTI2NCB3YXMgcGFydCBvZiB0aGUgb3JwaGFuZWQgaW5v
ZGUgbGlzdC4gIElHTk9SRUQuIApJbm9kZSA0NTA4OTI4MiB3YXMgcGFydCBv
ZiB0aGUgb3JwaGFuZWQgaW5vZGUgbGlzdC4gIElHTk9SRUQuIApJbm9kZSA0
NTA4OTI4NCB3YXMgcGFydCBvZiB0aGUgb3JwaGFuZWQgaW5vZGUgbGlzdC4g
IElHTk9SRUQuIApJbm9kZSA0NTA4OTI4NiB3YXMgcGFydCBvZiB0aGUgb3Jw
aGFuZWQgaW5vZGUgbGlzdC4gIElHTk9SRUQuIApJbm9kZSA0NTA4OTI5MSB3
YXMgcGFydCBvZiB0aGUgb3JwaGFuZWQgaW5vZGUgbGlzdC4gIElHTk9SRUQu
IApJbm9kZSA0NTA4OTI5NyB3YXMgcGFydCBvZiB0aGUgb3JwaGFuZWQgaW5v
ZGUgbGlzdC4gIElHTk9SRUQuIApJbm9kZSA0NTA4OTI5OCB3YXMgcGFydCBv
ZiB0aGUgb3JwaGFuZWQgaW5vZGUgbGlzdC4gIElHTk9SRUQuIApJbm9kZSA0
NTA4OTMwNSB3YXMgcGFydCBvZiB0aGUgb3JwaGFuZWQgaW5vZGUgbGlzdC4g
IElHTk9SRUQuIApJbm9kZSA0NTA4OTMwNyB3YXMgcGFydCBvZiB0aGUgb3Jw
aGFuZWQgaW5vZGUgbGlzdC4gIElHTk9SRUQuIApJbm9kZSA0NTA4OTMxOSB3
YXMgcGFydCBvZiB0aGUgb3JwaGFuZWQgaW5vZGUgbGlzdC4gIElHTk9SRUQu
IApJbm9kZSA0NTA4OTMyMCB3YXMgcGFydCBvZiB0aGUgb3JwaGFuZWQgaW5v
ZGUgbGlzdC4gIElHTk9SRUQuIApJbm9kZSA2MzcwNTkxOSB3YXMgcGFydCBv
ZiB0aGUgb3JwaGFuZWQgaW5vZGUgbGlzdC4gIElHTk9SRUQuIApJbm9kZSA2
NTkzODY4NyB3YXMgcGFydCBvZiB0aGUgb3JwaGFuZWQgaW5vZGUgbGlzdC4g
IElHTk9SRUQuIApJbm9kZSA2NTkzOTI1NiB3YXMgcGFydCBvZiB0aGUgb3Jw
aGFuZWQgaW5vZGUgbGlzdC4gIElHTk9SRUQuIApJbm9kZSA2NTkzOTM1NSB3
YXMgcGFydCBvZiB0aGUgb3JwaGFuZWQgaW5vZGUgbGlzdC4gIElHTk9SRUQu
IApJbm9kZSA2NTkzOTM2OCB3YXMgcGFydCBvZiB0aGUgb3JwaGFuZWQgaW5v
ZGUgbGlzdC4gIElHTk9SRUQuIApJbm9kZSA2NjE5MTY4NiB3YXMgcGFydCBv
ZiB0aGUgb3JwaGFuZWQgaW5vZGUgbGlzdC4gIElHTk9SRUQuIApJbm9kZSA2
NjE5MTY4OSB3YXMgcGFydCBvZiB0aGUgb3JwaGFuZWQgaW5vZGUgbGlzdC4g
IElHTk9SRUQuIApJbm9kZSA2NjE5MTczOCB3YXMgcGFydCBvZiB0aGUgb3Jw
aGFuZWQgaW5vZGUgbGlzdC4gIElHTk9SRUQuIApJbm9kZSA2NjE5MTc0MSB3
YXMgcGFydCBvZiB0aGUgb3JwaGFuZWQgaW5vZGUgbGlzdC4gIElHTk9SRUQu
IApJbm9kZSA2NjE5MTc0NyB3YXMgcGFydCBvZiB0aGUgb3JwaGFuZWQgaW5v
ZGUgbGlzdC4gIElHTk9SRUQuIApJbm9kZSA2NjE5Nzk3MCB3YXMgcGFydCBv
ZiB0aGUgb3JwaGFuZWQgaW5vZGUgbGlzdC4gIElHTk9SRUQuIApQYXNzIDI6
IENoZWNraW5nIGRpcmVjdG9yeSBzdHJ1Y3R1cmUgClBhc3MgMzogQ2hlY2tp
bmcgZGlyZWN0b3J5IGNvbm5lY3Rpdml0eSAKUGFzcyA0OiBDaGVja2luZyBy
ZWZlcmVuY2UgY291bnRzIApQYXNzIDU6IENoZWNraW5nIGdyb3VwIHN1bW1h
cnkgaW5mb3JtYXRpb24gCkJsb2NrIGJpdG1hcCBkaWZmZXJlbmNlczogIC0o
MjM5MzM0NC0tMjM5MzM3MikgLSgyMzkzNzkyLS0yMzkzODA5KSAtKDI0NzAy
NzItLTI0NzAzMzYpIC0oMjUwMjAxNi0tMjUwMjA4MCkgKyg3ODMxNTUyLS03
ODQxMjUyKSArKDc4NDE3OTItLTc4NjQzMTkpIC0oNzk3OTUyNTItLTc5Nzk1
MjUzKSAtKDc5ODIzNDg4LS03OTgyMzYxNSkgLSg3OTgyNDAwMC0tNzk4MjQx
MjMpIC0oNzk4MjQ2NDAtLTc5ODI1MTQyKSAtNzk4MjYzNDQgLTc5ODk4MDE0
IC03OTkyMzEwMSAtKDc5OTIzMTU0LS03OTkyMzE2NSkgLSg4MDEyMzI5Ni0t
ODAxMjMzMTEpIC0oODAxNTIyOTgtLTgwMTUyMzAxKSAtODAyOTE3MjkgLTgw
MjkxNzMyIC04MDI5MTc1OSAtODA4NDczODAgLSg4MDg0NzQzOC0tODA4NDc0
NDEpIC04MDg0NzUwMiAtODA4NDc1NTUgLTgwODQ3NzM2IC04MDg3NDY0NSAt
ODA4NzQ2NjQgLTgwODc1ODczIC0oODA4NzU5MTQtLTgwODc1OTIwKSAtODA4
NzU5MjcgLTgwODc1OTYwIC0oODA4NzYwMDItLTgwODc2MDA0KSAtODA4NzYw
NDggLSg4MDg3NjA1Mi0tODA4NzYwNTYpIC0oODA4NzY2MDAtLTgwODc2NjAx
KSAtKDgwODc2NjM5LS04MDg3NjY0MSkgLTgxMzMwNTE2IC0oODEzMzQ1Mjct
LTgxMzM0NTI4KSAtODEzMzQ1MzUgLSg4MTgyMTkxNS0tODE4MjE5NDcpIC0o
ODE4MjIxNzAtLTgxODIyMjA0KSAtKDgxODk0NTU5LS04MTg5NDU2MikgLTgx
OTIzMzE3IC04MTkyNTc0MyAtODE5MjU5MzQgLSg4MTkyNTk1MS0tODE5MjU5
NTIpIC0oODE5MjYwMDMtLTgxOTI2MDA0KSAtKDgxOTU2NzM1LS04MTk1NzYz
OCkgLSg4Mjk3MTczMi0tODI5NzE3MzMpIC0oODI5NzE5MDItLTgyOTcxOTAz
KSAtKDgyOTcxOTE3LS04Mjk3MTkxOCkgLSg4Mjk3MTk0Ny0tODI5NzE5NDgp
IC0oODI5NzE5NzItLTgyOTcxOTkxKSAtODU5OTIyMDMgLTg2NTE2NDgxIC04
NzYyNjM2MCAtODg2MTMyNzMgLTEwNDA4MzU5MiAtKDEwNDA4Mzk0Ni0tMTA0
MDgzOTQ4KSAtMTA0MDgzOTU3IC0xMDQwODQwNzMgLTEwNDA4NDA4NCAtMTA0
MDg0NDg3IC0xMDQxMzczOTcgLTEwNDEzODExMSAtMTA0MjM2NDMwIC0oMTA0
MjM2NTgwLS0xMDQyMzY1OTYpIC0oMTA0MjM2NTk4LS0xMDQyMzY2MTApIC0o
MTA0MzAxODE0LS0xMDQzMDE4MTUpIC0oMTA0MzAxODIyLS0xMDQzMDE4Mjgp
IC0xMDQzNDMwODAgLSgxMDU2ODY4NjMtLTEwNTY4Njg2NCkgLTEwNTY4Njkx
NiAtKDExNTkwMzA0MC0tMTE1OTAzMDY1KSArKDExNTkwMzUxNi0tMTE1OTAz
NTQxKSAtMTM0MjU5ODQ3IC0xMzQyODQyNDUgLTEzNDI4NDU5MyAtKDEzNDI4
NDY3NC0tMTM0Mjg0Njc1KSAtMTM0Mjg1NDczIC0oMTcwOTk0ODk2LS0xNzA5
OTQ5MDEpIC0xNzA5OTQ5NTkgLTE3MDk5NTAyNyAtKDE4MDM5NzU0NS0tMTgw
Mzk3NTQ3KSAtKDI1NTE2NzMyMi0tMjU1MTY3ODA1KSAtKDI2Mzc1NjUxMi0t
MjYzNzU2NTE2KSAtKDI2Mzc2NDgwMC0tMjYzNzY0ODA3KSAtKDI2Mzc3OTU2
OC0tMjYzNzc5NTkyKSAtKDI2Mzc4MjQ5OC0tMjYzNzgyNTMzKSAtKDI2NDc5
ODM0NC0tMjY0Nzk4MzQ4KSAtKDI2NDgwNDAxNi0tMjY0ODA0MDIzKSAtKDI2
NDgwNDA2NC0tMjY0ODA0MDc0KSAtKDI2NDgwNDk2OC0tMjY0ODA0OTczKSAt
KDI2NDgwOTIxNi0tMjY0ODA5MzU5KSAKRml4PyBubyAKCkZyZWUgYmxvY2tz
IGNvdW50IHdyb25nIGZvciBncm91cCAjMjM5ICg1MzksIGNvdW50ZWQ9MzI3
NjgpLiAKRml4PyBubyAKCkZyZWUgYmxvY2tzIGNvdW50IHdyb25nIGZvciBn
cm91cCAjMjQ0NiAoMjMwNTcsIGNvdW50ZWQ9MjMwNTMpLiAKRml4PyBubyAK
CkZyZWUgYmxvY2tzIGNvdW50IHdyb25nICgyNTY5MjE2MzgsIGNvdW50ZWQ9
MjU2NjQ2MDE3KS4gCkZpeD8gbm8gCgpJbm9kZSBiaXRtYXAgZGlmZmVyZW5j
ZXM6ICAtMjAxODYzMzIgLTIwMzE3NTA2IC0yMDMxNzU1MiAtMjAzMTc5NTUg
LTIwNDQ3MjM3IC0yMDQ0NzI0NSAtMjA0NDcyODcgLTIwNDQ3Mjk2IC0yMDQ0
NzMwMiAtMjA0NDczMTEgLTIwNDQ3MzUzIC0yMDQ0NzM2MCAtMjE1MDA3ODcg
LTIxNjI4OTEzIC0yMjE1ODgwOCAtMjIxNTg4MTEgLTIyMTU4ODQwIC0yMjE1
ODg0MiAtMjIxNTg4NDYgLTI1OTUyOTQ5IC0yNTk1MzQyNCAtMjU5NTQ1NDIg
LSg0NTA4ODc3MS0tNDUwODg3NzUpIC00NTA4ODk3MiAtNDUwODkwMjIgLTQ1
MDg5MDM1IC00NTA4OTAzNyAtKDQ1MDg5MDQzLS00NTA4OTA0NSkgLTQ1MDg5
MDU3IC00NTA4OTA2MCAtNDUwODkwNjIgLTQ1MDg5MDY0IC0oNDUwODkwNjct
LTQ1MDg5MDY4KSAtNDUwODkwNzAgLTQ1MDg5MTM3IC00NTA4OTE1MCAtNDUw
ODkxNTYgLTQ1MDg5MTkwIC0oNDUwODkyMDQtLTQ1MDg5MjA1KSAtNDUwODky
MDcgLTQ1MDg5MjEzIC00NTA4OTIxOCAtNDUwODkyMzggLTQ1MDg5MjQ5IC00
NTA4OTI1NyAtNDUwODkyNjQgLTQ1MDg5MjgyIC00NTA4OTI4NCAtNDUwODky
ODYgLTQ1MDg5MjkxIC0oNDUwODkyOTctLTQ1MDg5Mjk4KSAtNDUwODkzMDUg
LTQ1MDg5MzA3IC0oNDUwODkzMTktLTQ1MDg5MzIwKSAtNjM3MDU5MTkgLTY1
OTM4Njg3IC02NTkzOTI1NiAtNjU5MzkzNTUgLTY1OTM5MzY4IC02NjE5MTY4
NiAtNjYxOTE2ODkgLTY2MTkxNzM4IC02NjE5MTc0MSAtNjYxOTE3NDcgLTY2
MTk3OTcwIApGaXg/IG5vIAoKRGlyZWN0b3JpZXMgY291bnQgd3JvbmcgZm9y
IGdyb3VwICMyNjI0ICg3MzUsIGNvdW50ZWQ9NzM0KS4gCkZpeD8gbm8gCgpE
aXJlY3RvcmllcyBjb3VudCB3cm9uZyBmb3IgZ3JvdXAgIzI2NDAgKDczNSwg
Y291bnRlZD03MzQpLiAKRml4PyBubyAKCkRpcmVjdG9yaWVzIGNvdW50IHdy
b25nIGZvciBncm91cCAjMjcwNCAoNTQxLCBjb3VudGVkPTU0MCkuIApGaXg/
IG5vIAoKRnJlZSBpbm9kZXMgY291bnQgd3JvbmcgKDY4Mjk1NzgxLCBjb3Vu
dGVkPTY4MjY4MjM0KS4gCkZpeD8gbm8gCgoKL2Rldi9tZDI6ICoqKioqKioq
KiogV0FSTklORzogRmlsZXN5c3RlbSBzdGlsbCBoYXMgZXJyb3JzICoqKioq
KioqKiogCgovZGV2L21kMjogMTM3NzE3OS82OTY3Mjk2MCBmaWxlcyAoMC40
JSBub24tY29udGlndW91cyksIDIxNzY0ODI2LzI3ODY4NjQ2NCBibG9ja3Mg
CiMgCgojIGUyZnNjayAtZiAtbiAvZGV2L3NkYTQgCmUyZnNjayAxLjQxLjEy
ICgxNy1NYXktMjAxMCkgCmUyZnNjazogRGV2aWNlIG9yIHJlc291cmNlIGJ1
c3kgd2hpbGUgdHJ5aW5nIHRvIG9wZW4gL2Rldi9zZGE0IApGaWxlc3lzdGVt
IG1vdW50ZWQgb3Igb3BlbmVkIGV4Y2x1c2l2ZWx5IGJ5IGFub3RoZXIgcHJv
Z3JhbT8gCgojIG1kYWRtIC0tZGV0YWlsIC9kZXYvbWQyIAovZGV2L21kMjog
CiAgICAgICAgVmVyc2lvbiA6IDEuMSAKICBDcmVhdGlvbiBUaW1lIDogV2Vk
IE5vdiAyNCAwODoyNzo0MiAyMDEwIAogICAgIFJhaWQgTGV2ZWwgOiByYWlk
NiAKICAgICBBcnJheSBTaXplIDogMTExNDc0NTg1NiAoMTA2My4xMCBHaUIg
MTE0MS41MCBHQikgCiAgVXNlZCBEZXYgU2l6ZSA6IDM3MTU4MTk1MiAoMzU0
LjM3IEdpQiAzODAuNTAgR0IpIAogICBSYWlkIERldmljZXMgOiA1IAogIFRv
dGFsIERldmljZXMgOiA1IAogICAgUGVyc2lzdGVuY2UgOiBTdXBlcmJsb2Nr
IGlzIHBlcnNpc3RlbnQgCgogIEludGVudCBCaXRtYXAgOiBJbnRlcm5hbCAK
CiAgICBVcGRhdGUgVGltZSA6IFRodSBBcHIgIDcgMTI6MTE6NTkgMjAxMSAK
ICAgICAgICAgIFN0YXRlIDogYWN0aXZlIAogQWN0aXZlIERldmljZXMgOiA1
IApXb3JraW5nIERldmljZXMgOiA1IAogRmFpbGVkIERldmljZXMgOiAwIAog
IFNwYXJlIERldmljZXMgOiAwIAoKICAgICAgICAgTGF5b3V0IDogbGVmdC1z
eW1tZXRyaWMgCiAgICAgQ2h1bmsgU2l6ZSA6IDUxMksgCgogICAgICAgICAg
IE5hbWUgOiBsb2NhbGhvc3QubG9jYWxkb21haW46MiAKICAgICAgICAgICBV
VUlEIDogYTUxMWU2NTY6YTc0MmEyZjI6ZjQ5MTc5Mzk6MmQzMzNjN2UgCiAg
ICAgICAgIEV2ZW50cyA6IDM4NjA5IAoKICAgIE51bWJlciAgIE1ham9yICAg
TWlub3IgICBSYWlkRGV2aWNlIFN0YXRlIAogICAgICAgMCAgICAgICA4ICAg
ICAgICA0ICAgICAgICAwICAgICAgYWN0aXZlIHN5bmMgICAvZGV2L3NkYTQg
CiAgICAgICAxICAgICAgIDggICAgICAgNjggICAgICAgIDEgICAgICBhY3Rp
dmUgc3luYyAgIC9kZXYvc2RlNCAKICAgICAgIDUgICAgICAgOCAgICAgICAy
MCAgICAgICAgMiAgICAgIGFjdGl2ZSBzeW5jICAgL2Rldi9zZGI0IAogICAg
ICAgMyAgICAgICA4ICAgICAgIDUyICAgICAgICAzICAgICAgYWN0aXZlIHN5
bmMgICAvZGV2L3NkZDQgCiAgICAgICA2ICAgICAgIDggICAgICAgMzYgICAg
ICAgIDQgICAgICBhY3RpdmUgc3luYyAgIC9kZXYvc2RjNCAKIyAKCm5vdGUg
YWJzZW5jZSBvZiAvZGV2L21kMCAoc3dhcCkhISEKIyBkZiAKRmlsZXN5c3Rl
bSAgICAgICAgICAgMUstYmxvY2tzICAgICAgVXNlZCBBdmFpbGFibGUgVXNl
JSBNb3VudGVkIG9uIAovZGV2L21kMiAgICAgICAgICAgICAxMDk3MjU0NDA4
ICA3MDc5OTMyOCA5NzA3MTc3ODggICA3JSAvIAp0bXBmcyAgICAgICAgICAg
ICAgICAgIDQwOTcxMDggICAgICAgODI0ICAgNDA5NjI4NCAgIDElIC9kZXYv
c2htIAovZGV2L3NkYTEgICAgICAgICAgICAgIDEwMzIwODggICAgMTI4Nzcy
ICAgIDg1MDg4OCAgMTQlIC9ib290IAovZGV2L21kMSAgICAgICAgICAgICAz
MDIzNzc5MjAgIDcyNTAxNDI4IDIxNDUxNjU3MiAgMjYlIC9kYXRhIAojIAoK
IyBtZGFkbSAtRXZzIApBUlJBWSAvZGV2L21kMSBsZXZlbD1yYWlkNiBudW0t
ZGV2aWNlcz01IFVVSUQ9NmYxMTc2YWU6YTBhZDZjYWM6YmZlNzgwMTA6YmM4
MTBmMDQgCiAgIGRldmljZXM9L2Rldi9zZGUyLC9kZXYvc2RjMiwvZGV2L3Nk
ZDIsL2Rldi9zZGIyLC9kZXYvc2RhMiAKQVJSQVkgL2Rldi9tZDAgbGV2ZWw9
cmFpZDYgbnVtLWRldmljZXM9NSBVVUlEPTNiNzZhYzIwOjgyNTNmNjk2OmJm
ZTc4MDEwOmJjODEwZjA0IAogICBkZXZpY2VzPS9kZXYvc2RlMywvZGV2L3Nk
YzMsL2Rldi9zZGQzLC9kZXYvc2RiMywvZGV2L3NkYTMgCkFSUkFZIC9kZXYv
bWQvMiBsZXZlbD1yYWlkNiBtZXRhZGF0YT0xLjEgbnVtLWRldmljZXM9NSBV
VUlEPWE1MTFlNjU2OmE3NDJhMmYyOmY0OTE3OTM5OjJkMzMzYzdlIG5hbWU9
bG9jYWxob3N0LmxvY2FsZG9tYWluOjIgCiAgIGRldmljZXM9L2Rldi9zZGU0
LC9kZXYvc2RjNCwvZGV2L3NkZDQsL2Rldi9zZGI0LC9kZXYvc2RhNCAKIyAK
CiMgZmRpc2sgLWwgCgpEaXNrIC9kZXYvc2RhOiA1MDAuMSBHQiwgNTAwMTA3
ODYyMDE2IGJ5dGVzIAoyNTUgaGVhZHMsIDYzIHNlY3RvcnMvdHJhY2ssIDYw
ODAxIGN5bGluZGVycywgdG90YWwgOTc2NzczMTY4IHNlY3RvcnMgClVuaXRz
ID0gc2VjdG9ycyBvZiAxICogNTEyID0gNTEyIGJ5dGVzIApTZWN0b3Igc2l6
ZSAobG9naWNhbC9waHlzaWNhbCk6IDUxMiBieXRlcyAvIDUxMiBieXRlcyAK
SS9PIHNpemUgKG1pbmltdW0vb3B0aW1hbCk6IDUxMiBieXRlcyAvIDUxMiBi
eXRlcyAKRGlzayBpZGVudGlmaWVyOiAweDAwMDBjYTNhIAoKICAgRGV2aWNl
IEJvb3QgICAgICBTdGFydCAgICAgICAgIEVuZCAgICAgIEJsb2NrcyAgIElk
ICBTeXN0ZW0gCi9kZXYvc2RhMSAgICogICAgICAgICAgNjMgICAgIDIwOTcy
MTQgICAgIDEwNDg1NzYgICA4MyAgTGludXggCi9kZXYvc2RhMiAgICAgICAg
IDIwOTcyMTUgICAyMDY4OTcyMTQgICAxMDI0MDAwMDAgICBmZCAgTGludXgg
cmFpZCBhdXRvZGV0ZWN0IAovZGV2L3NkYTMgICAgICAgMjA2ODk3MjE1ICAg
MjE0MDY1MjE0ICAgICAzNTg0MDAwICAgZmQgIExpbnV4IHJhaWQgYXV0b2Rl
dGVjdCAKL2Rldi9zZGE0ICAgICAgIDIxNDA2NjEyNSAgIDk1NzIzMzAyNCAg
IDM3MTU4MzQ1MCAgIGZkICBMaW51eCByYWlkIGF1dG9kZXRlY3QgCgpEaXNr
IC9kZXYvc2RiOiA1MDAuMSBHQiwgNTAwMTA3ODYyMDE2IGJ5dGVzIAoyNTUg
aGVhZHMsIDYzIHNlY3RvcnMvdHJhY2ssIDYwODAxIGN5bGluZGVycywgdG90
YWwgOTc2NzczMTY4IHNlY3RvcnMgClVuaXRzID0gc2VjdG9ycyBvZiAxICog
NTEyID0gNTEyIGJ5dGVzIApTZWN0b3Igc2l6ZSAobG9naWNhbC9waHlzaWNh
bCk6IDUxMiBieXRlcyAvIDUxMiBieXRlcyAKSS9PIHNpemUgKG1pbmltdW0v
b3B0aW1hbCk6IDUxMiBieXRlcyAvIDUxMiBieXRlcyAKRGlzayBpZGVudGlm
aWVyOiAweDAwMDU2NmMxIAoKICAgRGV2aWNlIEJvb3QgICAgICBTdGFydCAg
ICAgICAgIEVuZCAgICAgIEJsb2NrcyAgIElkICBTeXN0ZW0gCi9kZXYvc2Ri
MSAgICAgICAgICAgICAgNjMgICAgIDIwOTcyMTQgICAgIDEwNDg1NzYgICA4
MyAgTGludXggCi9kZXYvc2RiMiAgICAgICAgIDIwOTcyMTUgICAyMDY4OTcy
MTQgICAxMDI0MDAwMDAgICBmZCAgTGludXggcmFpZCBhdXRvZGV0ZWN0IAov
ZGV2L3NkYjMgICAgICAgMjA2ODk3MjE1ICAgMjE0MDY1MjE0ICAgICAzNTg0
MDAwICAgZmQgIExpbnV4IHJhaWQgYXV0b2RldGVjdCAKL2Rldi9zZGI0ICAg
ICAgIDIxNDA2NjEyNSAgIDk1NzIzMzAyNCAgIDM3MTU4MzQ1MCAgIGZkICBM
aW51eCByYWlkIGF1dG9kZXRlY3QgCgpEaXNrIC9kZXYvc2RkOiA1MDAuMSBH
QiwgNTAwMTA3ODYyMDE2IGJ5dGVzIAoyNTUgaGVhZHMsIDYzIHNlY3RvcnMv
dHJhY2ssIDYwODAxIGN5bGluZGVycywgdG90YWwgOTc2NzczMTY4IHNlY3Rv
cnMgClVuaXRzID0gc2VjdG9ycyBvZiAxICogNTEyID0gNTEyIGJ5dGVzIApT
ZWN0b3Igc2l6ZSAobG9naWNhbC9waHlzaWNhbCk6IDUxMiBieXRlcyAvIDUx
MiBieXRlcyAKSS9PIHNpemUgKG1pbmltdW0vb3B0aW1hbCk6IDUxMiBieXRl
cyAvIDUxMiBieXRlcyAKRGlzayBpZGVudGlmaWVyOiAweDAwMDBhZjc5IAoK
ICAgRGV2aWNlIEJvb3QgICAgICBTdGFydCAgICAgICAgIEVuZCAgICAgIEJs
b2NrcyAgIElkICBTeXN0ZW0gCi9kZXYvc2RkMSAgICogICAgICAgICAgNjMg
ICAgIDIwOTcyMTQgICAgIDEwNDg1NzYgICA4MyAgTGludXggCi9kZXYvc2Rk
MiAgICAgICAgIDIwOTcyMTUgICAyMDY4OTcyMTQgICAxMDI0MDAwMDAgICBm
ZCAgTGludXggcmFpZCBhdXRvZGV0ZWN0IAovZGV2L3NkZDMgICAgICAgMjA2
ODk3MjE1ICAgMjE0MDY1MjE0ICAgICAzNTg0MDAwICAgZmQgIExpbnV4IHJh
aWQgYXV0b2RldGVjdCAKL2Rldi9zZGQ0ICAgICAgIDIxNDA2NjEyNSAgIDk1
NzIzMzAyNCAgIDM3MTU4MzQ1MCAgIGZkICBMaW51eCByYWlkIGF1dG9kZXRl
Y3QgCgpEaXNrIC9kZXYvc2RjOiA1MDAuMSBHQiwgNTAwMTA3ODYyMDE2IGJ5
dGVzIAoyNTUgaGVhZHMsIDYzIHNlY3RvcnMvdHJhY2ssIDYwODAxIGN5bGlu
ZGVycywgdG90YWwgOTc2NzczMTY4IHNlY3RvcnMgClVuaXRzID0gc2VjdG9y
cyBvZiAxICogNTEyID0gNTEyIGJ5dGVzIApTZWN0b3Igc2l6ZSAobG9naWNh
bC9waHlzaWNhbCk6IDUxMiBieXRlcyAvIDUxMiBieXRlcyAKSS9PIHNpemUg
KG1pbmltdW0vb3B0aW1hbCk6IDUxMiBieXRlcyAvIDUxMiBieXRlcyAKRGlz
ayBpZGVudGlmaWVyOiAweDAwMDgxY2NkIAoKICAgRGV2aWNlIEJvb3QgICAg
ICBTdGFydCAgICAgICAgIEVuZCAgICAgIEJsb2NrcyAgIElkICBTeXN0ZW0g
Ci9kZXYvc2RjMSAgICogICAgICAgICAgNjMgICAgIDIwOTcyMTQgICAgIDEw
NDg1NzYgICA4MyAgTGludXggCi9kZXYvc2RjMiAgICAgICAgIDIwOTcyMTUg
ICAyMDY4OTcyMTQgICAxMDI0MDAwMDAgICBmZCAgTGludXggcmFpZCBhdXRv
ZGV0ZWN0IAovZGV2L3NkYzMgICAgICAgMjA2ODk3MjE1ICAgMjE0MDY1MjE0
ICAgICAzNTg0MDAwICAgZmQgIExpbnV4IHJhaWQgYXV0b2RldGVjdCAKL2Rl
di9zZGM0ICAgICAgIDIxNDA2NjEyNSAgIDk1NzIzMzAyNCAgIDM3MTU4MzQ1
MCAgIGZkICBMaW51eCByYWlkIGF1dG9kZXRlY3QgCgpEaXNrIC9kZXYvc2Rl
OiA1MDAuMSBHQiwgNTAwMTA3ODYyMDE2IGJ5dGVzIAoyNTUgaGVhZHMsIDYz
IHNlY3RvcnMvdHJhY2ssIDYwODAxIGN5bGluZGVycywgdG90YWwgOTc2Nzcz
MTY4IHNlY3RvcnMgClVuaXRzID0gc2VjdG9ycyBvZiAxICogNTEyID0gNTEy
IGJ5dGVzIApTZWN0b3Igc2l6ZSAobG9naWNhbC9waHlzaWNhbCk6IDUxMiBi
eXRlcyAvIDUxMiBieXRlcyAKSS9PIHNpemUgKG1pbmltdW0vb3B0aW1hbCk6
IDUxMiBieXRlcyAvIDUxMiBieXRlcyAKRGlzayBpZGVudGlmaWVyOiAweDAw
MDgxY2NkIAoKICAgRGV2aWNlIEJvb3QgICAgICBTdGFydCAgICAgICAgIEVu
ZCAgICAgIEJsb2NrcyAgIElkICBTeXN0ZW0gCi9kZXYvc2RlMSAgICogICAg
ICAgICAgNjMgICAgIDIwOTcyMTQgICAgIDEwNDg1NzYgICA4MyAgTGludXgg
Ci9kZXYvc2RlMiAgICAgICAgIDIwOTcyMTUgICAyMDY4OTcyMTQgICAxMDI0
MDAwMDAgICBmZCAgTGludXggcmFpZCBhdXRvZGV0ZWN0IAovZGV2L3NkZTMg
ICAgICAgMjA2ODk3MjE1ICAgMjE0MDY1MjE0ICAgICAzNTg0MDAwICAgZmQg
IExpbnV4IHJhaWQgYXV0b2RldGVjdCAKL2Rldi9zZGU0ICAgICAgIDIxNDA2
NjEyNSAgIDk1NzIzMzAyNCAgIDM3MTU4MzQ1MCAgIGZkICBMaW51eCByYWlk
IGF1dG9kZXRlY3QgCgpEaXNrIC9kZXYvbWQwOiAxMS4wIEdCLCAxMTAwOTg1
MTM5MiBieXRlcyAKMiBoZWFkcywgNCBzZWN0b3JzL3RyYWNrLCAyNjg3OTUy
IGN5bGluZGVycywgdG90YWwgMjE1MDM2MTYgc2VjdG9ycyAKVW5pdHMgPSBz
ZWN0b3JzIG9mIDEgKiA1MTIgPSA1MTIgYnl0ZXMgClNlY3RvciBzaXplIChs
b2dpY2FsL3BoeXNpY2FsKTogNTEyIGJ5dGVzIC8gNTEyIGJ5dGVzIApJL08g
c2l6ZSAobWluaW11bS9vcHRpbWFsKTogNjU1MzYgYnl0ZXMgLyAxOTY2MDgg
Ynl0ZXMgCkRpc2sgaWRlbnRpZmllcjogMHgwMDAwMDAwMCAKCkRpc2sgL2Rl
di9tZDAgZG9lc24ndCBjb250YWluIGEgdmFsaWQgcGFydGl0aW9uIHRhYmxl
IAoKRGlzayAvZGV2L21kMTogMzE0LjYgR0IsIDMxNDU3MTIyNzEzNiBieXRl
cyAKMiBoZWFkcywgNCBzZWN0b3JzL3RyYWNrLCA3Njc5OTYxNiBjeWxpbmRl
cnMsIHRvdGFsIDYxNDM5NjkyOCBzZWN0b3JzIApVbml0cyA9IHNlY3RvcnMg
b2YgMSAqIDUxMiA9IDUxMiBieXRlcyAKU2VjdG9yIHNpemUgKGxvZ2ljYWwv
cGh5c2ljYWwpOiA1MTIgYnl0ZXMgLyA1MTIgYnl0ZXMgCkkvTyBzaXplICht
aW5pbXVtL29wdGltYWwpOiA1MjQyODggYnl0ZXMgLyAxNTcyODY0IGJ5dGVz
IApEaXNrIGlkZW50aWZpZXI6IDB4MDAwMDAwMDAgCgpEaXNrIC9kZXYvbWQx
IGRvZXNuJ3QgY29udGFpbiBhIHZhbGlkIHBhcnRpdGlvbiB0YWJsZSAKCkRp
c2sgL2Rldi9tZDI6IDExNDEuNSBHQiwgMTE0MTQ5OTc1NjU0NCBieXRlcyAK
MiBoZWFkcywgNCBzZWN0b3JzL3RyYWNrLCAyNzg2ODY0NjQgY3lsaW5kZXJz
LCB0b3RhbCAyMjI5NDkxNzEyIHNlY3RvcnMgClVuaXRzID0gc2VjdG9ycyBv
ZiAxICogNTEyID0gNTEyIGJ5dGVzIApTZWN0b3Igc2l6ZSAobG9naWNhbC9w
aHlzaWNhbCk6IDUxMiBieXRlcyAvIDUxMiBieXRlcyAKSS9PIHNpemUgKG1p
bmltdW0vb3B0aW1hbCk6IDUyNDI4OCBieXRlcyAvIDE1NzI4NjQgYnl0ZXMg
CkRpc2sgaWRlbnRpZmllcjogMHgwMDAwMDAwMCAKCkRpc2sgL2Rldi9tZDIg
ZG9lc24ndCBjb250YWluIGEgdmFsaWQgcGFydGl0aW9uIHRhYmxlIAojIAoK
IyBkbXJhaWQgLWIgCi9kZXYvc2RlOiAgICA5NzY3NzMxNjggdG90YWwsICI2
Vk0yRkU2NCIgCi9kZXYvc2RjOiAgICA5NzY3NzMxNjggdG90YWwsICI1Vk1K
M1JKRSIgCi9kZXYvc2RkOiAgICA5NzY3NzMxNjggdG90YWwsICI2Vk0yQU05
OCIgCi9kZXYvc2RiOiAgICA5NzY3NzMxNjggdG90YWwsICI2Vk0ySDVXNyIg
Ci9kZXYvc2RhOiAgICA5NzY3NzMxNjggdG90YWwsICI1Vk0xVk5NOSIgCiMg
CgpJIHJhbiBiYWRibG9ja3MgZm9yIGVhY2ggZHJpdmUgY29uY3VycmVudGx5
LCBub3RlIHRoYXQgdGhlIG9uZSBmb3Igc2RhIHRvb2sgYWJvdXQgYW4gaG91
ciBsb25nZXIgdGhhbiB0aGUgb3RoZXJzLCBidXQgaXQgd2FzIHNkYyB0aGF0
IHJlcG9ydGVkIGEgYmFkIGJsb2NrLgojIGJhZGJsb2NrcyAtcyAtdiAvZGV2
L3NkYSAKQ2hlY2tpbmcgYmxvY2tzIDAgdG8gNDg4Mzg2NTgzIApDaGVja2lu
ZyBmb3IgYmFkIGJsb2NrcyAocmVhZC1vbmx5IHRlc3QpOiBkb25lICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAKUGFzcyBjb21wbGV0ZWQsIDAg
YmFkIGJsb2NrcyBmb3VuZC4gCiMgYmFkYmxvY2tzIC1zIC12IC9kZXYvc2Ri
IApDaGVja2luZyBibG9ja3MgMCB0byA0ODgzODY1ODMgCkNoZWNraW5nIGZv
ciBiYWQgYmxvY2tzIChyZWFkLW9ubHkgdGVzdCk6IGRvbmUgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIApQYXNzIGNvbXBsZXRlZCwgMCBiYWQg
YmxvY2tzIGZvdW5kLiAKIyBiYWRibG9ja3MgLXMgLXYgL2Rldi9zZGMgCkNo
ZWNraW5nIGJsb2NrcyAwIHRvIDQ4ODM4NjU4MyAKQ2hlY2tpbmcgZm9yIGJh
ZCBibG9ja3MgKHJlYWQtb25seSB0ZXN0KTogMjM2ODE3MTUyb25lLCA1ODo0
MyBlbGFwc2VkIApkb25lICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAKUGFzcyBjb21wbGV0ZWQsIDEgYmFkIGJsb2NrcyBmb3VuZC4gCiMgYmFk
YmxvY2tzIC1zIC12IC9kZXYvc2RkIApDaGVja2luZyBibG9ja3MgMCB0byA0
ODgzODY1ODMgCkNoZWNraW5nIGZvciBiYWQgYmxvY2tzIChyZWFkLW9ubHkg
dGVzdCk6IGRvbmUgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIApQ
YXNzIGNvbXBsZXRlZCwgMCBiYWQgYmxvY2tzIGZvdW5kLiAKIyBiYWRibG9j
a3MgLXMgLXYgL2Rldi9zZGUgCkNoZWNraW5nIGJsb2NrcyAwIHRvIDQ4ODM4
NjU4MyAKQ2hlY2tpbmcgZm9yIGJhZCBibG9ja3MgKHJlYWQtb25seSB0ZXN0
KTogZG9uZSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgClBhc3Mg
Y29tcGxldGVkLCAwIGJhZCBibG9ja3MgZm91bmQuIAojClNlbGVjdGVkIGxp
bmVzIGZyb20gdGhlIHNtYXJ0Y3RsIG91dHB1dDoKIyBzbWFydGN0bCAtYSAv
ZGV2L3NkYSAKTW9kZWwgRmFtaWx5OiAgICAgU2VhZ2F0ZSBCYXJyYWN1ZGEg
NzIwMC4xMiBmYW1pbHkgCkRldmljZSBNb2RlbDogICAgIFNUMzUwMDQxOEFT
IApTZXJpYWwgTnVtYmVyOiAgICA1Vk0xVk5NOSAKICA1IFJlYWxsb2NhdGVk
X1NlY3Rvcl9DdCAgIDB4MDAzMyAgIDEwMCAgIDEwMCAgIDAzNiAgICBQcmUt
ZmFpbCAgQWx3YXlzICAgICAgIC0gICAgICAgMTcgCgoKIyBzbWFydGN0bCAt
YSAvZGV2L3NkYiAKTW9kZWwgRmFtaWx5OiAgICAgU2VhZ2F0ZSBCYXJyYWN1
ZGEgNzIwMC4xMiBmYW1pbHkgCkRldmljZSBNb2RlbDogICAgIFNUMzUwMDQx
OEFTIApTZXJpYWwgTnVtYmVyOiAgICA2Vk0ySDVXNyAKICA1IFJlYWxsb2Nh
dGVkX1NlY3Rvcl9DdCAgIDB4MDAzMyAgIDA5OSAgIDA5OSAgIDAzNiAgICBQ
cmUtZmFpbCAgQWx3YXlzICAgICAgIC0gICAgICAgNDIgCgoKIyBzbWFydGN0
bCAtYSAvZGV2L3NkYyAKTW9kZWwgRmFtaWx5OiAgICAgU2VhZ2F0ZSBCYXJy
YWN1ZGEgNzIwMC4xMiBmYW1pbHkgCkRldmljZSBNb2RlbDogICAgIFNUMzUw
MDQxOEFTIApTZXJpYWwgTnVtYmVyOiAgICA1Vk1KM1JKRSAKICA1IFJlYWxs
b2NhdGVkX1NlY3Rvcl9DdCAgIDB4MDAzMyAgIDEwMCAgIDEwMCAgIDAzNiAg
ICBQcmUtZmFpbCAgQWx3YXlzICAgICAgIC0gICAgICAgMCAKCgojIHNtYXJ0
Y3RsIC1hIC9kZXYvc2RkIApNb2RlbCBGYW1pbHk6ICAgICBTZWFnYXRlIEJh
cnJhY3VkYSA3MjAwLjEyIGZhbWlseSAKRGV2aWNlIE1vZGVsOiAgICAgU1Qz
NTAwNDE4QVMgClNlcmlhbCBOdW1iZXI6ICAgIDZWTTJBTTk4IAogIDUgUmVh
bGxvY2F0ZWRfU2VjdG9yX0N0ICAgMHgwMDMzICAgMTAwICAgMTAwICAgMDM2
ICAgIFByZS1mYWlsICBBbHdheXMgICAgICAgLSAgICAgICAxIAoKCiMgc21h
cnRjdGwgLWEgL2Rldi9zZGUgCk1vZGVsIEZhbWlseTogICAgIFNlYWdhdGUg
QmFycmFjdWRhIDcyMDAuMTIgZmFtaWx5IApEZXZpY2UgTW9kZWw6ICAgICBT
VDM1MDA0MThBUyAKU2VyaWFsIE51bWJlcjogICAgNlZNMkZFNjQgCiAgNSBS
ZWFsbG9jYXRlZF9TZWN0b3JfQ3QgICAweDAwMzMgICAwOTkgICAwOTkgICAw
MzYgICAgUHJlLWZhaWwgIEFsd2F5cyAgICAgICAtICAgICAgIDc5IAoKCg==


--0-1335622535-1302226463=:10299--
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: RAID6 data-check took almost 2 hours, clicking sounds, system unresponsive

Hi Neil,

Looks like the log file was simply too big.

Here are the initial and ending lines:

Cheers,
Gavin

output of:
grep -i ATA /var/log/messages

Apr 4 00:46:18 saturn kernel: [58150.946089] pata_atiixp 0000:00:14.1:=
PCI INT A disabled
Apr 4 00:46:19 saturn kernel: [58151.620996] pata_atiixp 0000:00:14.1:=
PCI INT A -> GSI 16 (level, low) -> IRQ 16
Apr 4 00:46:19 saturn kernel: [58151.776364] ata6.00: ACPI cmd ef/03:0=
c:00:00:00:a0 (SET FEATURES) filtered out
Apr 4 00:46:19 saturn kernel: [58151.776367] ata6.00: ACPI cmd ef/03:4=
6:00:00:00:a0 (SET FEATURES) filtered out
Apr 4 00:46:19 saturn kernel: [58151.776370] ata6.00: ACPI cmd f5/00:0=
0:00:00:00:a0 (SECURITY FREEZE LOCK) filtered out
Apr 4 00:46:19 saturn kernel: [58151.792475] ata5.00: ACPI cmd ef/03:0=
c:00:00:00:a0 (SET FEATURES) filtered out
Apr 4 00:46:19 saturn kernel: [58151.792478] ata5.00: ACPI cmd ef/03:4=
2:00:00:00:a0 (SET FEATURES) filtered out
Apr 4 00:46:19 saturn kernel: [58151.792481] ata5.00: ACPI cmd f5/00:0=
0:00:00:00:a0 (SECURITY FREEZE LOCK) filtered out
Apr 4 00:46:19 saturn kernel: [58151.814455] ata5.00: configured for U=
DMA/33
Apr 4 00:46:19 saturn kernel: [58151.850339] ata6.00: configured for U=
DMA/100
Apr 4 00:46:19 saturn kernel: [58151.864031] ata3: softreset failed (d=
evice not ready)
Apr 4 00:46:19 saturn kernel: [58151.864035] ata4: softreset failed (d=
evice not ready)
Apr 4 00:46:19 saturn kernel: [58151.864038] ata3: applying SB600 PMP =
SRST workaround and retrying
Apr 4 00:46:19 saturn kernel: [58151.864040] ata4: applying SB600 PMP =
SRST workaround and retrying
Apr 4 00:46:19 saturn kernel: [58151.864059] ata2: softreset failed (d=
evice not ready)
Apr 4 00:46:19 saturn kernel: [58151.864061] ata1: softreset failed (d=
evice not ready)
Apr 4 00:46:19 saturn kernel: [58151.864063] ata2: applying SB600 PMP =
SRST workaround and retrying
Apr 4 00:46:19 saturn kernel: [58151.864065] ata1: applying SB600 PMP =
SRST workaround and retrying
Apr 4 00:46:19 saturn kernel: [58152.019042] ata2: SATA link up 3.0 Gb=
ps (SStatus 123 SControl 300)
Apr 4 00:46:19 saturn kernel: [58152.019046] ata4: SATA link up 3.0 Gb=
ps (SStatus 123 SControl 300)
Apr 4 00:46:19 saturn kernel: [58152.019070] ata3: SATA link up 3.0 Gb=
ps (SStatus 123 SControl 300)
Apr 4 00:46:19 saturn kernel: [58152.019079] ata1: SATA link up 3.0 Gb=
ps (SStatus 123 SControl 300)
Apr 4 00:46:19 saturn kernel: [58152.021363] ata3.00: configured for U=
DMA/133
Apr 4 00:46:19 saturn kernel: [58152.085139] ata4.00: configured for U=
DMA/133
Apr 4 00:46:19 saturn kernel: [58152.085152] ata1.00: configured for U=
DMA/133
Apr 4 00:46:19 saturn kernel: [58152.085165] ata2.00: configured for U=
DMA/133
[...]
Apr 7 14:41:58 saturn kernel: [231943.624749] ata3: hard resetting lin=
k
Apr 7 14:42:05 saturn kernel: [231950.625059] ata3: SATA link up 1.5 G=
bps (SStatus 113 SControl 310)
Apr 7 14:42:05 saturn kernel: [231950.635608] ata3.00: configured for =
UDMA/33
Apr 7 14:42:05 saturn kernel: [231950.635617] ata3: EH complete
Apr 7 14:42:05 saturn kernel: [231950.654531] ata3.00: exception Emask=
0x50 SAct 0x1 SErr 0x90a00 action 0xe frozen
Apr 7 14:42:05 saturn kernel: [231950.654535] ata3.00: irq_stat 0x0140=
0000, PHY RDY changed
Apr 7 14:42:05 saturn kernel: [231950.654538] ata3: SError: { Persist =
HostInt PHYRdyChg 10B8B }
Apr 7 14:42:05 saturn kernel: [231950.654541] ata3.00: failed command:=
READ FPDMA QUEUED
Apr 7 14:42:05 saturn kernel: [231950.654546] ata3.00: cmd 60/80:00:f0=
:21:3b/00:00:1c:00:00/40 tag 0 ncq 65536 in
Apr 7 14:42:05 saturn kernel: [231950.654547] res 40/00:00:f0=
:21:3b/00:00:1c:00:00/40 Emask 0x50 (ATA bus error)
Apr 7 14:42:05 saturn kernel: [231950.654550] ata3.00: status: { DRDY =
}
Apr 7 14:42:05 saturn kernel: [231950.654554] ata3: hard resetting lin=
k
Apr 7 14:42:12 saturn kernel: [231957.654285] ata3: SATA link up 1.5 G=
bps (SStatus 113 SControl 310)
Apr 7 14:42:12 saturn kernel: [231957.666115] ata3.00: configured for =
UDMA/33
Apr 7 14:42:12 saturn kernel: [231957.666123] ata3: EH complete
Apr 7 14:42:12 saturn kernel: [231957.756013] ata3.00: exception Emask=
0x50 SAct 0x1 SErr 0x90a00 action 0xe frozen
Apr 7 14:42:12 saturn kernel: [231957.756016] ata3.00: irq_stat 0x0140=
0000, PHY RDY changed
Apr 7 14:42:12 saturn kernel: [231957.756020] ata3: SError: { Persist =
HostInt PHYRdyChg 10B8B }
Apr 7 14:42:12 saturn kernel: [231957.756023] ata3.00: failed command:=
READ FPDMA QUEUED
Apr 7 14:42:12 saturn kernel: [231957.756028] ata3.00: cmd 60/80:00:f0=
:24:3b/00:00:1c:00:00/40 tag 0 ncq 65536 in
Apr 7 14:42:12 saturn kernel: [231957.756029] res 40/00:00:f0=
:24:3b/00:00:1c:00:00/40 Emask 0x50 (ATA bus error)
Apr 7 14:42:12 saturn kernel: [231957.756032] ata3.00: status: { DRDY =
}
Apr 7 14:42:12 saturn kernel: [231957.756037] ata3: hard resetting lin=
k
Apr 7 14:42:16 saturn kernel: [231961.389026] ata3: softreset failed (=
device not ready)
Apr 7 14:42:16 saturn kernel: [231961.389032] ata3: applying SB600 PMP=
SRST workaround and retrying
Apr 7 14:42:16 saturn kernel: [231961.544030] ata3: SATA link up 1.5 G=
bps (SStatus 113 SControl 310)
Apr 7 14:42:16 saturn kernel: [231961.546323] ata3.00: configured for =
UDMA/33
Apr 7 14:42:16 saturn kernel: [231961.546331] ata3: EH complete

--
All Adults share the Responsibility
to help Raise Today's Children,
for they are Tomorrow's Society!


--- On Fri, 8/4/11, Gavin Flower wrote:

> From: Gavin Flower
> Subject: RAID6 data-check took almost 2 hours, clicking sounds, syste=
m unresponsive
> To: neilb@suse.de
> Cc: linux-raid@vger.kernel.org
> Date: Friday, 8 April, 2011, 13:32
[...]
> My original email may have been eaten: as it did not appear
> on the list, nor did I get an error message back.=A0 So
> perhaps there was a problem with the attached files.
>=20
> I will resend the attachments one at a time in separate
> emails.
[...]
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" i=
n
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: RAID6 data-check took almost 2 hours, clicking sounds, systemunresponsive

On Thu, 7 Apr 2011 18:32:04 -0700 (PDT) Gavin Flower
wrote:

> Hi Neil,
>
> My original email may have been eaten: as it did not appear on the list, nor did I get an error message back. So perhaps there was a problem with the attached files.
>
> I will resend the attachments one at a time in separate emails.
>
>
> Cheers,
> Gavin
>
> [begin original]
> Hi Neil,
>
> Your help (or anybody else's) would be greatly appreciated, yet again

Hi Gavin,
it isn't clear to me what help you want.

Obviously there is some sort of hardware issue - possible a drive, possibly a
bus problem - I really don't know.

Apart from that things look normal.

What exactly did you want explained?

NeilBrown


>
> This morning, I noticed my system was extremely unresponsive, and that there were clicking sounds coming from one of my 5 hard drives. Also that there was excessive disk I/O even for trivial things like bring up a directory window, and lots of ata3 errors being reported to the system log. These symptoms were mostly during a raid check process.
>
> Somewhere along the way, I seemed to have lost my swap partition!
>
> So I did some extensive investigations, which took most of the day. My notes were created in OpenDocument format using LibreOffice, but I have converted them to txt format for the include - but I can supply the ,odt file if requested.
>
> I Have included 2 files:
> my notes: raid-notes-20110407a.txt
> selected log entries: messages-gcf-20110407-ATA
>
> If there are some additional diagnostics that might prove useful, please let me know.
>
>
> Cheers,
> Gavin
> [end original]
> --
> All Adults share the Responsibility
> to help Raise Today's Children,
> for they are Tomorrow's Society!
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: RAID6 data-check took almost 2 hours, clicking sounds, system unresponsive

--- On Fri, 8/4/11, NeilBrown wrote:

> From: NeilBrown
> Subject: Re: RAID6 data-check took almost 2 hours, clicking sounds, s=
ystem unresponsive
> To: "Gavin Flower"
> Cc: linux-raid@vger.kernel.org
> Date: Friday, 8 April, 2011, 21:34
> On Thu, 7 Apr 2011 18:32:04 -0700
> (PDT) Gavin Flower
> wrote:
>=20
> > Hi Neil,
> >=20
> > My original email may have been eaten: as it did not
> appear on the list, nor did I get an error message
> back.=A0 So perhaps there was a problem with the attached
> files.
> >=20
> > I will resend the attachments one at a time in
> separate emails.
> >=20
> >=20
> > Cheers,
> > Gavin
> >=20
> > [begin original]
> > Hi Neil,
> >=20
> > Your help (or anybody else's) would be greatly
> appreciated, yet again
>=20
> Hi Gavin,
> it isn't clear to me what help you want.
>=20
> Obviously there is some sort of hardware issue - possible a
> drive, possibly a
> bus problem - I really don't know.
>=20
> Apart from that things look normal.
>=20
> What exactly did you want explained?
>=20
> NeilBrown

I guess I was surprised that the RAID system appeared normal and that i=
t did not register any errors. I was hoping to get an idea as to which=
drive was problematic.

I get the feeling, from your reply, that this is not specifically a RAI=
D problem, that it just happens to affect a RAID array.

I had thought that the RAID system should have been able to give me bet=
ter diagnostics, but possibly I am being (inadvertently) unreasonable!

Not sure what the significance of this mismatch is, and what I should d=
o about it.
# cat /sys/block/md2/md/mismatch_cnt=20
28904=20
#=20


Thanks,
Gavin

> >=20
> > This morning, I noticed my system was extremely
> unresponsive, and that there were clicking sounds coming
> from one of my 5 hard drives.=A0 Also that there was
> excessive disk I/O even for trivial things like bring up a
> directory window, and lots of ata3 errors being reported to
> the system log.=A0 These symptoms were mostly during a
> raid check process.
> >=20
> > Somewhere along the way, I seemed to have lost my swap
> partition!
> >=20
> > So I did some extensive investigations, which took
> most of the day.=A0 My notes were created in OpenDocument
> format using LibreOffice, but I have converted them to txt
> format for the include - but I can supply the ,odt file if
> requested.
> >=20
> > I Have included 2 files:
> >=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0
> my notes: raid-notes-20110407a.txt
> >=A0 =A0 selected log entries:
> messages-gcf-20110407-ATA
> >=20
> > If there are some additional diagnostics that might
> prove useful, please let me know.
> >=20
> >=20
> > Cheers,
> > Gavin
> > [end original]
> > --
> > All Adults share the Responsibility
> > to help Raise Today's Children,
> > for they are Tomorrow's Society!
> > --
> > To unsubscribe from this list: send the line
> "unsubscribe linux-raid" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at=A0 http://vger.kernel.org/majordomo-info.htm=
l
>=20
>=20
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" i=
n
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: RAID6 data-check took almost 2 hours, clicking sounds, systemunresponsive

On Fri, 8 Apr 2011 02:59:52 -0700 (PDT) Gavin Flower com>
wrote:

>=20
> --- On Fri, 8/4/11, NeilBrown wrote:
>=20
> > From: NeilBrown
> > Subject: Re: RAID6 data-check took almost 2 hours, clicking sounds,=
system unresponsive
> > To: "Gavin Flower"
> > Cc: linux-raid@vger.kernel.org
> > Date: Friday, 8 April, 2011, 21:34
> > On Thu, 7 Apr 2011 18:32:04 -0700
> > (PDT) Gavin Flower
> > wrote:
> >=20
> > > Hi Neil,
> > >=20
> > > My original email may have been eaten: as it did not
> > appear on the list, nor did I get an error message
> > back.=A0 So perhaps there was a problem with the attached
> > files.
> > >=20
> > > I will resend the attachments one at a time in
> > separate emails.
> > >=20
> > >=20
> > > Cheers,
> > > Gavin
> > >=20
> > > [begin original]
> > > Hi Neil,
> > >=20
> > > Your help (or anybody else's) would be greatly
> > appreciated, yet again
> >=20
> > Hi Gavin,
> > it isn't clear to me what help you want.
> >=20
> > Obviously there is some sort of hardware issue - possible a
> > drive, possibly a
> > bus problem - I really don't know.
> >=20
> > Apart from that things look normal.
> >=20
> > What exactly did you want explained?
> >=20
> > NeilBrown
>=20
> I guess I was surprised that the RAID system appeared normal and that=
it did not register any errors. I was hoping to get an idea as to whi=
ch drive was problematic.

sdc2 was reporting read error. md/raid6 computed the data from the oth=
er
devices and wrote it back to sdc2. This appeared to work so md/raid6 a=
ssumed
everything was fine again. It reported this:

Apr 7 08:42:08 saturn kernel: [210414.109880] md/raid:md1: read error =
corrected (8 sectors at 17195840 on sdc2)=20

but didn't fail anything.


>=20
> I get the feeling, from your reply, that this is not specifically a R=
AID problem, that it just happens to affect a RAID array.

No, it was clearly a disk-drive problem.
e.g.
Apr 7 14:42:12 saturn kernel: [231957.756023] ata3.00: failed command:=
READ FPDMA QUEUED

a READ command sent to a n 'ata' device failed. i.e. disk error.

>=20
> I had thought that the RAID system should have been able to give me b=
etter diagnostics, but possibly I am being (inadvertently) unreasonable=
!

Well.... it did tell you that it got a read error and corrected it.


>=20
> Not sure what the significance of this mismatch is, and what I should=
do about it.
> # cat /sys/block/md2/md/mismatch_cnt=20
> 28904=20
> #=20

I'm not sure if read errors end up counting as mismatches.. They seem =
to for
raid1. The raid6 code is more complex and I don't feel like decoding i=
t
right now.

In terms of "what to do about it" - the first thing must be to fix sdc.
Maybe there is a loose cable or a broken cable. Maybe the device needs=
to be
replaced.

Once you have resolved that and are fairly sure yours drives are all wo=
rking,
echo check > /sys/block/md2/md/sync_action

once that finishes mismatch_cnt should ideally be zero. If it isn't, t=
ry
echo repair > /sys/block/md2/md/sync_action

but only do that if you are confident that your devices are good.
This will result in the same mismatch_cnt. However a subsequent 'check=
'
should then show zero.

NeilBrown



--
To unsubscribe from this list: send the line "unsubscribe linux-raid" i=
n
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: RAID6 data-check took almost 2 hours, clicking sounds, system unresponsive

--- On Fri, 8/4/11, NeilBrown wrote:

> From: NeilBrown
> Subject: Re: RAID6 data-check took almost 2 hours, clicking sounds, s=
ystem unresponsive
> To: "Gavin Flower"
> Cc: linux-raid@vger.kernel.org
> Date: Friday, 8 April, 2011, 23:50
> On Fri, 8 Apr 2011 02:59:52 -0700
> (PDT) Gavin Flower
> wrote:
>=20
> >=20
> > --- On Fri, 8/4/11, NeilBrown
> wrote:
> >=20
> > > From: NeilBrown
> > > Subject: Re: RAID6 data-check took almost 2
> hours, clicking sounds, system unresponsive
[...]
> > > Obviously there is some sort of hardware issue -
> possible a
> > > drive, possibly a
> > > bus problem - I really don't know.
> > >=20
> > > Apart from that things look normal.
> > >=20
> > > What exactly did you want explained?
> > >=20
> > > NeilBrown
> >=20
> > I guess I was surprised that the RAID system appeared
> normal and that it did not register any errors.=A0 I was
> hoping to get an idea as to which drive was problematic.
>=20
> sdc2 was reporting read error.=A0 md/raid6 computed the
> data from the other
> devices and wrote it back to sdc2.=A0 This appeared to
> work so md/raid6 assumed
> everything was fine again.=A0 It reported this:
>=20
> Apr=A0 7 08:42:08 saturn kernel: [210414.109880]
> md/raid:md1: read error corrected (8 sectors at 17195840 on
> sdc2)=20
>=20
> but didn't fail anything.
>=20
>=20
> >=20
> > I get the feeling, from your reply, that this is not
> specifically a RAID problem, that it just happens to affect
> a RAID array.
>=20
> No, it was clearly a disk-drive problem.
> e.g.
> Apr=A0 7 14:42:12 saturn kernel: [231957.756023]
> ata3.00: failed command: READ FPDMA QUEUED
>=20
> a READ command sent to a n 'ata' device failed.=A0 i.e.
> disk error.
>=20
> >=20
> > I had thought that the RAID system should have been
> able to give me better diagnostics, but possibly I am being
> (inadvertently) unreasonable!
>=20
> Well.... it did tell you that it got a read error and
> corrected it.
>=20
>=20
> >=20
> > Not sure what the significance of this mismatch is,
> and what I should do about it.
> > # cat /sys/block/md2/md/mismatch_cnt=20
> > 28904=20
> > #=20
>=20
> I'm not sure if read errors end up counting as
> mismatches..=A0 They seem to for
> raid1.=A0 The raid6 code is more complex and I don't
> feel like decoding it
> right now.
>=20
> In terms of "what to do about it" - the first thing must be
> to fix sdc.
> Maybe there is a loose cable or a broken cable.=A0 Maybe
> the device needs to be
> replaced.
>=20
> Once you have resolved that and are fairly sure yours
> drives are all working,
> =A0 =A0 echo check >
> /sys/block/md2/md/sync_action
>=20
> once that finishes mismatch_cnt should ideally be
> zero.=A0 If it isn't, try
> =A0 =A0 echo repair >
> /sys/block/md2/md/sync_action
>=20
> but only do that if you are confident that your devices are
> good.
> This will result in the same mismatch_cnt.=A0 However a
> subsequent 'check'
> should then show zero.
>=20
> NeilBrown

Thanks,

I followed your suggestions and all 'appears' to be fine now.

Reality was a wee bit more dramatic than I would have liked!

Machine refused to boot this morning, complaining about disk errors. F=
ortunately, I had arranged for a hardware capable friend to come around=
He adjusted the cable on the offending drive and I ran fsck twice (=
lots of alarming messages first time). On rebooting, the system came up=
, but a video driver problem prevented the desktop from working. Fortu=
nately I was able to log in from another machine and apply your suggest=
ed remedy. After the repair, I rebooted and was able to get into my de=
sktop, subsequent checks revealed the mismatch counts to be all zero (I=
checked the failed RAID array and the other 2)


--
To unsubscribe from this list: send the line "unsubscribe linux-raid" i=
n
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: RAID6 data-check took almost 2 hours, clicking sounds, system unresponsive

--- On Fri, 8/4/11, NeilBrown wrote:
[...]
> No, it was clearly a disk-drive problem.
> e.g.
> Apr 7 14:42:12 saturn kernel: [231957.756023]
> ata3.00: failed command: READ FPDMA QUEUED
>
> a READ command sent to a n 'ata' device failed. i.e.
> disk error.
[...]

Hi Neil,

I think it is either a drive or cable problem.

However, I was wondering if /proc/mdstat could list drives in a more consistent manner. The C drive has dropped out and affected all 3 RAID partitions. A quick look at /proc/mdstat suggests that md2 & md1 have the same drive drop out [UUUU_], but a different drive for md0 [UU_UU]. In fact, the list of drives (...sda4[0] sdc4[6](F)...) is not consistent with the [UUUU_] representation even for the same mdN!

# date ; cat /proc/mdstat
Wed Apr 13 08:40:09 NZST 2011
Personalities : [raid6] [raid5] [raid4]

md2 : active raid6 sda4[0] sdc4[6](F) sdd4[3] sdb4[5] sde4[1]
1114745856 blocks super 1.1 level 6, 512k chunk, algorithm 2 [5/4] [UUUU_]
bitmap: 3/3 pages [12KB], 65536KB chunk

md1 : active raid6 sda2[0] sdc2[5](F) sdd2[3] sde2[2] sdb2[1]
307198464 blocks level 6, 512k chunk, algorithm 2 [5/4] [UUUU_]

md0 : active raid6 sda3[0] sdb3[4] sdd3[3] sdc3[5](F) sde3[1]
10751808 blocks level 6, 64k chunk, algorithm 2 [5/4] [UU_UU]

unused devices:
#


Regards,
Gavin


--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: RAID6 data-check took almost 2 hours, clicking sounds, systemunresponsive

On 12/04/2011 22:30, Gavin Flower wrote:
> --- On Fri, 8/4/11, NeilBrown wrote:
> [...]
>> No, it was clearly a disk-drive problem.
>> e.g.
>> Apr 7 14:42:12 saturn kernel: [231957.756023]
>> ata3.00: failed command: READ FPDMA QUEUED
>>
>> a READ command sent to a n 'ata' device failed. i.e.
>> disk error.
> [...]
>
> Hi Neil,
>
> I think it is either a drive or cable problem.
>
> However, I was wondering if /proc/mdstat could list drives in a more consistent manner. The C drive has dropped out and affected all 3 RAID partitions. A quick look at /proc/mdstat suggests that md2& md1 have the same drive drop out [UUUU_], but a different drive for md0 [UU_UU]. In fact, the list of drives (...sda4[0] sdc4[6](F)...) is not consistent with the [UUUU_] representation even for the same mdN!
>
> # date ; cat /proc/mdstat
> Wed Apr 13 08:40:09 NZST 2011
> Personalities : [raid6] [raid5] [raid4]
>
> md2 : active raid6 sda4[0] sdc4[6](F) sdd4[3] sdb4[5] sde4[1]
> 1114745856 blocks super 1.1 level 6, 512k chunk, algorithm 2 [5/4] [UUUU_]

This looks correct: sorting the first line into md slot order we have:
md2 : active raid6 sda4[0] sde4[1] sdd4[3] sdb4[5] sdc4[6](F)
which is UUUU_

> md1 : active raid6 sda2[0] sdc2[5](F) sdd2[3] sde2[2] sdb2[1]
> 307198464 blocks level 6, 512k chunk, algorithm 2 [5/4] [UUUU_]

Similarly:
md1 : active raid6 sda2[0] sdb2[1] sde2[2] sdd2[3] sdc2[5](F)
which is UUUU_

> md0 : active raid6 sda3[0] sdb3[4] sdd3[3] sdc3[5](F) sde3[1]
> 10751808 blocks level 6, 64k chunk, algorithm 2 [5/4] [UU_UU]

This one I don't get:
md0 : active raid6 sda3[0] sde3[1] sdd3[3] sdb3[4] sdc3[5](F)
which ought to be UUUU_ again...

Perhaps `mdadm -D /dev/md[0-2]` would make things clearer...

Cheers,

John.

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: RAID6 data-check took almost 2 hours, clicking sounds, systemunresponsive

On Wed, 13 Apr 2011 11:57:24 +0100 John Robinson
wrote:

> On 12/04/2011 22:30, Gavin Flower wrote:
> > --- On Fri, 8/4/11, NeilBrown wrote:
> > [...]
> >> No, it was clearly a disk-drive problem.
> >> e.g.
> >> Apr 7 14:42:12 saturn kernel: [231957.756023]
> >> ata3.00: failed command: READ FPDMA QUEUED
> >>
> >> a READ command sent to a n 'ata' device failed. i.e.
> >> disk error.
> > [...]
> >
> > Hi Neil,
> >
> > I think it is either a drive or cable problem.
> >
> > However, I was wondering if /proc/mdstat could list drives in a more consistent manner. The C drive has dropped out and affected all 3 RAID partitions. A quick look at /proc/mdstat suggests that md2& md1 have the same drive drop out [UUUU_], but a different drive for md0 [UU_UU]. In fact, the list of drives (...sda4[0] sdc4[6](F)...) is not consistent with the [UUUU_] representation even for the same mdN!
> >
> > # date ; cat /proc/mdstat
> > Wed Apr 13 08:40:09 NZST 2011
> > Personalities : [raid6] [raid5] [raid4]
> >
> > md2 : active raid6 sda4[0] sdc4[6](F) sdd4[3] sdb4[5] sde4[1]
> > 1114745856 blocks super 1.1 level 6, 512k chunk, algorithm 2 [5/4] [UUUU_]
>
> This looks correct: sorting the first line into md slot order we have:
> md2 : active raid6 sda4[0] sde4[1] sdd4[3] sdb4[5] sdc4[6](F)
> which is UUUU_
>
> > md1 : active raid6 sda2[0] sdc2[5](F) sdd2[3] sde2[2] sdb2[1]
> > 307198464 blocks level 6, 512k chunk, algorithm 2 [5/4] [UUUU_]
>
> Similarly:
> md1 : active raid6 sda2[0] sdb2[1] sde2[2] sdd2[3] sdc2[5](F)
> which is UUUU_
>
> > md0 : active raid6 sda3[0] sdb3[4] sdd3[3] sdc3[5](F) sde3[1]
> > 10751808 blocks level 6, 64k chunk, algorithm 2 [5/4] [UU_UU]
>
> This one I don't get:
> md0 : active raid6 sda3[0] sde3[1] sdd3[3] sdb3[4] sdc3[5](F)
> which ought to be UUUU_ again...
>
> Perhaps `mdadm -D /dev/md[0-2]` would make things clearer...
>

This is actually more horrible than you imagine.

The number [] is not the role of the device in the raid. Rather it is an
arbitrarily assigned slot number with no real meaning.

The original 0.90 metadata format has two numbers for each device.
These are in mdp_disk_t defined in include/linux/raid/md_p.h

They are 'number' which is the slot number and so is defined for spare
devices as well as active devices.
And there is the 'raid_disk' number which is the role that the device
plays in the array and is well defined for active devices and
meaningless for spares.

mdstat always showed the 'number'.

However the 0.90 format keeps 'number' and 'raid_disk' the same for active
devices (so why have two different numbers - who knows).
So people reasonably jumped to the technically wrong conclusion that the
number inside [] was the role number.

In 1.x, I keep the slot 'number' the same for the life of a device, but change
the role - from 'spare' to and active role to 'failed' - because this makes
sense.
However that means that the number in [] definitely isn't the role number any
more. It might be when the array is created, but it is not certain to stay
that way.

As the current number is pretty much useless, I should probably change it to
the slot number, or an arbitrarily assigned larger number for spares.
This would be an incompatible change, but I very much doubt anyone uses the
numbers for what they actually are, so I doubt that would really matter.

It has just never really got high on my list of priorities....

Lesson: Ignore the number in [] - it doesn't mean anything useful.

NeilBrown
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: RAID6 data-check took almost 2 hours, clicking sounds, systemunresponsive

On 13/04/2011 12:13, NeilBrown wrote:
> On Wed, 13 Apr 2011 11:57:24 +0100 John Robinson
> wrote:
>> On 12/04/2011 22:30, Gavin Flower wrote:
[...]
>>> md0 : active raid6 sda3[0] sdb3[4] sdd3[3] sdc3[5](F) sde3[1]
>>> 10751808 blocks level 6, 64k chunk, algorithm 2 [5/4] [UU_UU]
>>
>> This one I don't get:
>> md0 : active raid6 sda3[0] sde3[1] sdd3[3] sdb3[4] sdc3[5](F)
>> which ought to be UUUU_ again...
>>
>> Perhaps `mdadm -D /dev/md[0-2]` would make things clearer...
>
> This is actually more horrible than you imagine.

It isn't really, I was asking for the mdadm -D output precisely to get
the list of role and slot numbers, having noticed there was no slot 2 in
Gavin's setup...

[...]
> As the current number is pretty much useless, I should probably change it to
> the slot number, or an arbitrarily assigned larger number for spares.
> This would be an incompatible change, but I very much doubt anyone uses the
> numbers for what they actually are, so I doubt that would really matter.
>
> It has just never really got high on my list of priorities....
>
> Lesson: Ignore the number in [] - it doesn't mean anything useful.

It's not useless, it reflects the order in which devices were added to
the array.

Suggestion: Don't change the number in /proc/mdstat, just sort the
devices by role (i.e. the same order as the UUUU_) instead of device
node, and show spares at the end (as per your arbitrarily-assigned
larger number, which this way you never have to display).

Cheers,

John.
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: RAID6 data-check took almost 2 hours, clicking sounds, system unresponsive

--- On Wed, 13/4/11, John Robinson wro=
te:

> From: John Robinson
> Subject: Re: RAID6 data-check took almost 2 hours, clicking sounds, s=
ystem unresponsive
> To: "NeilBrown"
> Cc: "Gavin Flower" , linux-raid@vger.kernel.or=
g
> Date: Wednesday, 13 April, 2011, 23:58
> On 13/04/2011 12:13, NeilBrown
> wrote:
> > On Wed, 13 Apr 2011 11:57:24 +0100 John Robinson
> > =A0
> wrote:
> >> On 12/04/2011 22:30, Gavin Flower wrote:
> [...]
> >>> md0 : active raid6 sda3[0] sdb3[4] sdd3[3]
> sdc3[5](F) sde3[1]
> >>>=A0 =A0 =A0   =A010751808
> blocks level 6, 64k chunk, algorithm 2 [5/4] [UU_UU]
> >>=20
> >> This one I don't get:
> >> md0 : active raid6 sda3[0] sde3[1] sdd3[3] sdb3[4]
> sdc3[5](F)
> >> which ought to be UUUU_ again...
> >>=20
> >> Perhaps `mdadm -D /dev/md[0-2]` would make things
> clearer...
> >=20
> > This is actually more horrible than you imagine.
>=20
> It isn't really, I was asking for the mdadm -D output
> precisely to get the list of role and slot numbers, having
> noticed there was no slot 2 in Gavin's setup...
>=20
> [...]
> > As the current number is pretty much useless, I should
> probably change it to
> > the slot number, or an arbitrarily assigned larger
> number for spares.
> > This would be an incompatible change, but I very much
> doubt anyone uses the
> > numbers for what they actually are, so I doubt that
> would really matter.
> >=20
> > It has just never really got high on my list of
> priorities....
> >=20
> > Lesson:=A0 Ignore the number in [] - it doesn't
> mean anything useful.
>=20
> It's not useless, it reflects the order in which devices
> were added to the array.
>=20
> Suggestion: Don't change the number in /proc/mdstat, just
> sort the devices by role (i.e. the same order as the UUUU_)
> instead of device node, and show spares at the end (as per
> your arbitrarily-assigned larger number, which this way you
> never have to display).
>=20
> Cheers,
>=20
> John.
>=20

The first time I saw this kind of thing: I was very worried, thinking I=
had 2 bad drives - until I looked more closely, a few hours later. I =
am sure I am not the only to initially react that way.

=46rom a user perspective, I think that the list of drives and the [UUU=
U_] string, should be ordered in the alphanumeric order of the logical =
drive names. Also modify the '[...]' string to indicate spares (not hav=
ing spares, not sure what it does now).

e.g.
/dev/sda /dev/sdb /dev/sdc[F} /dev/sdd /dev/sde[S} /dev/sdf.
would be reflected by:
[aaFaSa]

Not sure what the 'U' stood for. Marking actives disks with 'a' seems t=
o make more sense to me. The upper and lower case would make it easier=
to see what is active and what is not. Similarly, the RAID entries wo=
uld be better, from a user perspective, to be sorted on name.

There are probably lots of technical reasons this can't be done, but us=
ers don't care! :-) We just want it to look pretty, be easy to underst=
and, and not be scary.

Just my 2 pennies worth...

When I put my developer hat on, I tend to feel that users rate looking =
pretty' and 'not be scary' as being more important than 'be easy to und=
erstand' - or perhaps, I am too cynical


--
To unsubscribe from this list: send the line "unsubscribe linux-raid" i=
n
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: RAID6 data-check took almost 2 hours, clicking sounds, system unresponsive

--- On Fri, 8/4/11, Gavin Flower wrote:

> From: Gavin Flower
> Subject: RAID6 data-check took almost 2 hours, clicking sounds, syste=
m unresponsive
[...]
> This morning, I noticed my system was extremely
> unresponsive, and that there were clicking sounds coming
> from one of my 5 hard drives. 
[...]

Hi Neil,

When I do=20
badblocks -s -v /dev/sdc
I hear clicking sounds from the hard drive, and notice lots and lots of=
log messages such as:
ata3: exception Emask 0x10 SAct 0x0 SErr 0x90200 action 0xe frozen
ata3: irq_stat 0x00400000, PHY RDY changed
ata3: SError: { Persist PHYRdyChg 10B8B }
ata3: hard resetting link
ata3: softreset failed (device not ready)
ata3: applying SB600 PMP SRST workaround and retrying
ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
ata3.00: configured for UDMA/33
ata3: EH complete

So I assume that the clicking corresponds to the hard reset, but I'm no=
t certain of that. Initially, I thought it might be some kind of disk =
head problems. Note that smart reports no bad blocks.


Regards,
Gavin

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" i=
n
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: RAID6 data-check took almost 2 hours, clicking sounds, system unresponsive

On 13 April 2011 23:24, Gavin Flower wrote:
>
> --- On Fri, 8/4/11, Gavin Flower wrote:
>
>> From: Gavin Flower
>> Subject: RAID6 data-check took almost 2 hours, clicking sounds, syst=
em unresponsive
> [...]
>> This morning, I noticed my system was extremely
>> unresponsive, and that there were clicking sounds coming
>> from one of my 5 hard drives.
> [...]
>
> Hi Neil,
>
> When I do
>   badblocks -s -v /dev/sdc
> I hear clicking sounds from the hard drive, and notice lots and lots =
of log messages such as:
> ata3: exception Emask 0x10 SAct 0x0 SErr 0x90200 action 0xe frozen
> ata3: irq_stat 0x00400000, PHY RDY changed
> ata3: SError: { Persist PHYRdyChg 10B8B }
> ata3: hard resetting link
> ata3: softreset failed (device not ready)
> ata3: applying SB600 PMP SRST workaround and retrying
> ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
> ata3.00: configured for UDMA/33
> ata3: EH complete
>
> So I assume that the clicking corresponds to the hard reset, but I'm =
not certain of that.  Initially, I thought it might be some kind o=
f disk head problems.  Note that smart reports no bad blocks.
>
>
> Regards,
> Gavin
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid"=
in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.ht=
ml
>

Perhaps you could post the full smartctl -a output?

Regards,
Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" i=
n
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: RAID6 data-check took almost 2 hours, clicking sounds, systemunresponsive

On Wed, 13 Apr 2011 15:24:17 -0700 (PDT) Gavin Flower o.com>
wrote:

>=20
> --- On Fri, 8/4/11, Gavin Flower wrote:
>=20
> > From: Gavin Flower
> > Subject: RAID6 data-check took almost 2 hours, clicking sounds, sys=
tem unresponsive
> [...]
> > This morning, I noticed my system was extremely
> > unresponsive, and that there were clicking sounds coming
> > from one of my 5 hard drives. 
> [...]
>=20
> Hi Neil,
>=20
> When I do=20
> badblocks -s -v /dev/sdc
> I hear clicking sounds from the hard drive, and notice lots and lots =
of log messages such as:
> ata3: exception Emask 0x10 SAct 0x0 SErr 0x90200 action 0xe frozen
> ata3: irq_stat 0x00400000, PHY RDY changed
> ata3: SError: { Persist PHYRdyChg 10B8B }
> ata3: hard resetting link
> ata3: softreset failed (device not ready)
> ata3: applying SB600 PMP SRST workaround and retrying
> ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 310)
> ata3.00: configured for UDMA/33
> ata3: EH complete
>=20
> So I assume that the clicking corresponds to the hard reset, but I'm =
not certain of that. Initially, I thought it might be some kind of dis=
k head problems. Note that smart reports no bad blocks.
>=20
>=20
> Regards,
> Gavin
>=20

This completely out side of my area of expertise.

My approach to such issues is to replace bits until the issue goes away=
, and
the last bit I replaced goes in the bin (after suitable double-checks) =
or
back to the supplier.

NeilBrown
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" i=
n
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: RAID6 data-check took almost 2 hours, clicking sounds, system unresponsive

--- On Thu, 14/4/11, Mathias Bur=E9n wrote:

> From: Mathias Bur=E9n
> Subject: Re: RAID6 data-check took almost 2 hours, clicking sounds, s=
ystem unresponsive
> To: "Gavin Flower"
> Cc: neilb@suse.de, linux-raid@vger.kernel.org
> Date: Thursday, 14 April, 2011, 10:28
> On 13 April 2011 23:24, Gavin Flower
>
> wrote:
> >
> > --- On Fri, 8/4/11, Gavin Flower
> wrote:
> >
> >> From: Gavin Flower
> >> Subject: RAID6 data-check took almost 2 hours,
> clicking sounds, system unresponsive
> > [...]
> >> This morning, I noticed my system was extremely
> >> unresponsive, and that there were clicking sounds
> coming
> >> from one of my 5 hard drives.
> > [...]
> >
> > Hi Neil,
> >
> > When I do
> > badblocks -s -v /dev/sdc
> > I hear clicking sounds from the hard drive, and notice
> lots and lots of log messages such as:
> > ata3: exception Emask 0x10 SAct 0x0 SErr 0x90200
> action 0xe frozen
> > ata3: irq_stat 0x00400000, PHY RDY changed
> > ata3: SError: { Persist PHYRdyChg 10B8B }
> > ata3: hard resetting link
> > ata3: softreset failed (device not ready)
> > ata3: applying SB600 PMP SRST workaround and retrying
> > ata3: SATA link up 1.5 Gbps (SStatus 113 SControl
> 310)
> > ata3.00: configured for UDMA/33
> > ata3: EH complete
> >
> > So I assume that the clicking corresponds to the hard
> reset, but I'm not certain of that. Initially, I thought
> it might be some kind of disk head problems. Note that
> smart reports no bad blocks.
> >
> >
> > Regards,
> > Gavin
> >
> > --
> > To unsubscribe from this list: send the line
> "unsubscribe linux-raid" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
>=20
> Perhaps you could post the full smartctl -a output?
>=20
> Regards,
> Mathias
>=20

Hi Mathias,

I was more commenting on the clicking sound, rather than asking for hel=
p! However, I am happy to oblige, output follows later.

I am happy to provide additional diagnostics and log messages, should t=
hey be of use.


Regards,
Gavin

# smartctl -a /dev/sdc
smartctl 5.40 2010-10-16 r3189 [x86_64-redhat-linux-gnu] (local build)
Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.=
net

===3D START OF INFORMATION SECTION ===3D
Model Family: Seagate Barracuda 7200.12 family
Device Model: ST3500418AS
Serial Number: 5VMJ3RJE
=46irmware Version: CC38
User Capacity: 500,107,862,016 bytes
Device is: In smartctl database [for details use: -P show]
ATA Version is: 8
ATA Standard is: ATA-8-ACS revision 4
Local Time is: Thu Apr 14 12:08:18 2011 NZST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

===3D START OF READ SMART DATA SECTION ===3D
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status: (0x82) Offline data collection activit=
y
was completed without error.
Auto Offline Data Collection: Enabled.
Self-test execution status: ( 0) The previous self-test routine =
completed
without error or no self-test has ever=20
been run.
Total time to complete Offline=20
data collection: ( 600) seconds.
Offline data collection
capabilities: (0x7b) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before enterin=
g
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine=20
recommended polling time: ( 1) minutes.
Extended self-test routine
recommended polling time: ( 85) minutes.
Conveyance self-test routine
recommended polling time: ( 2) minutes.
SCT capabilities: (0x103f) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table supported.

SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDAT=
ED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000f 115 099 006 Pre-fail Alway=
s - 87918991
3 Spin_Up_Time 0x0003 099 097 000 Pre-fail Alway=
s - 0
4 Start_Stop_Count 0x0032 085 085 020 Old_age Alway=
s - 16014
5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Alway=
s - 0
7 Seek_Error_Rate 0x000f 072 060 030 Pre-fail Alway=
s - 20251386
9 Power_On_Hours 0x0032 097 097 000 Old_age Alway=
s - 2940
10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Alway=
s - 0
12 Power_Cycle_Count 0x0032 093 093 020 Old_age Alway=
s - 7999
183 Runtime_Bad_Block 0x0032 076 076 000 Old_age Alway=
s - 24
184 End-to-End_Error 0x0032 100 100 099 Old_age Alway=
s - 0
187 Reported_Uncorrect 0x0032 100 100 000 Old_age Alway=
s - 0
188 Command_Timeout 0x0032 100 099 000 Old_age Alway=
s - 1
189 High_Fly_Writes 0x003a 100 100 000 Old_age Alway=
s - 0
190 Airflow_Temperature_Cel 0x0022 067 055 045 Old_age Alway=
s - 33 (Min/Max 17/33)
194 Temperature_Celsius 0x0022 033 045 000 Old_age Alway=
s - 33 (0 16 0 0)
195 Hardware_ECC_Recovered 0x001a 031 026 000 Old_age Alway=
s - 87918991
197 Current_Pending_Sector 0x0012 100 100 000 Old_age Alway=
s - 0
198 Offline_Uncorrectable 0x0010 100 100 000 Old_age Offli=
ne - 0
199 UDMA_CRC_Error_Count 0x003e 200 200 000 Old_age Alway=
s - 0
240 Head_Flying_Hours 0x0000 100 253 000 Old_age Offli=
ne - 225696236445405
241 Total_LBAs_Written 0x0000 100 253 000 Old_age Offli=
ne - 134453215
242 Total_LBAs_Read 0x0000 100 253 000 Old_age Offli=
ne - 846601860

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(ho=
urs) LBA_of_first_error
# 1 Short offline Completed without error 00% 3 =
-

SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute de=
lay.

#=20

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" i=
n
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: RAID6 data-check took almost 2 hours, clicking sounds, systemunresponsive

--Sig_/SMb7Rs82iz_2Pe+Ep1tjeuu
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Wed, 13 Apr 2011 17:15:42 -0700 (PDT)
Gavin Flower wrote:

> Note that smart reports no bad blocks.

It reports 24 bad blocks:

183 Runtime_Bad_Block 0x0032 076 076 000 Old_age Always
- 24

Try running a long SMART self test on the drive (smartctl -t long /dev/sdX).

Also for a bit of common sense - why not just try the disk on another PC. I=
f it
produces clicking sounds and "frozen" errors when running "badblocks" even
there, then what else do you expect it to do, jump out of the PC and say "i=
'm
broken please replace me"? :)

--=20
With respect,
Roman

--Sig_/SMb7Rs82iz_2Pe+Ep1tjeuu
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk2mczcACgkQTLKSvz+PZwiRAwCfeFV5DGpSNG8VQLvoG0H1 LYE4
CSEAoIPwCoS2bELQ5wF6s9PADrQZiTAG
=4hOH
-----END PGP SIGNATURE-----

--Sig_/SMb7Rs82iz_2Pe+Ep1tjeuu--
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: RAID6 data-check took almost 2 hours, clicking sounds, systemunresponsive

Hi Gavin,

I think you might want to investigate your *power supply* ...

On 04/13/2011 08:15 PM, Gavin Flower wrote:

[snip /]

> SMART Attributes Data Structure revision number: 10
> Vendor Specific SMART Attributes with Thresholds:
> ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
> 1 Raw_Read_Error_Rate 0x000f 115 099 006 Pre-fail Always - 87918991
> 3 Spin_Up_Time 0x0003 099 097 000 Pre-fail Always - 0
> 4 Start_Stop_Count 0x0032 085 085 020 Old_age Always - 16014
> 5 Reallocated_Sector_Ct 0x0033 100 100 036 Pre-fail Always - 0
> 7 Seek_Error_Rate 0x000f 072 060 030 Pre-fail Always - 20251386
> 9 Power_On_Hours 0x0032 097 097 000 Old_age Always - 2940
> 10 Spin_Retry_Count 0x0013 100 100 097 Pre-fail Always - 0
> 12 Power_Cycle_Count 0x0032 093 093 020 Old_age Always - 7999

SMOKING GUN ^^^^

I suspect your power supply is good enough to slowly spin up your drives and get them talking, but when you ask them to work hard, especially when writing, the PS voltage dips enough to reset the drive.

Look up all the power consumption specs for all of your components, and add up the *peak* current requirements. Make sure your PS can handle it.

HTH,

Phil
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: RAID6 data-check took almost 2 hours, clicking sounds, system unresponsive

--- On Fri, 15/4/11, Phil Turmel wrote:

> From: Phil Turmel
> Subject: Re: RAID6 data-check took almost 2 hours, clicking sounds, s=
ystem unresponsive
> To: "Gavin Flower"
> Cc: "Mathias Bur=E9n" , neilb@suse.de, linux=
-raid@vger.kernel.org
> Date: Friday, 15 April, 2011, 1:16
> Hi Gavin,
>=20
> I think you might want to investigate your *power supply*
> ...
>=20
> On 04/13/2011 08:15 PM, Gavin Flower wrote:
>=20
> [snip /]
>=20
> > SMART Attributes Data Structure revision number: 10
> > Vendor Specific SMART Attributes with Thresholds:
> > ID# ATTRIBUTE_NAME=A0 =A0 =A0 =A0 =A0
> FLAG=A0   =A0VALUE WORST THRESH TYPE=A0
> =A0 =A0 UPDATED=A0 WHEN_FAILED RAW_VALUE
> >  =A01 Raw_Read_Error_Rate=A0
>   =A00x000f  =A0115  =A0099  =A0006=A0
> =A0 Pre-fail=A0 Always=A0 =A0
>   =A0-=A0 =A0   =A087918991
> >  =A03 Spin_Up_Time=A0 =A0 =A0
> =A0 =A0 =A0
> 0x0003  =A0099  =A0097  =A0000=A0
> =A0 Pre-fail=A0 Always=A0 =A0
>   =A0-=A0 =A0   =A00
> >  =A04 Start_Stop_Count=A0 =A0
> =A0 =A0
> 0x0032  =A0085  =A0085  =A0020=A0
> =A0 Old_age  =A0Always=A0 =A0
>   =A0-=A0 =A0   =A016014
> >  =A05
> Reallocated_Sector_Ct  =A00x0033  =A0100  =A0100   =A0=
036=A0
> =A0 Pre-fail=A0 Always=A0 =A0
>   =A0-=A0 =A0   =A00
> >  =A07 Seek_Error_Rate=A0 =A0 =A0
>   =A00x000f  =A0072  =A0060  =A0030=A0
> =A0 Pre-fail=A0 Always=A0 =A0
>   =A0-=A0 =A0   =A020251386
> >  =A09 Power_On_Hours=A0 =A0 =A0
> =A0 =A0
> 0x0032  =A0097  =A0097  =A0000=A0
> =A0 Old_age  =A0Always=A0 =A0
>   =A0-=A0 =A0   =A02940
> >=A0 10 Spin_Retry_Count=A0 =A0 =A0 =A0
> 0x0013  =A0100  =A0100  =A0097=A0
> =A0 Pre-fail=A0 Always=A0 =A0
>   =A0-=A0 =A0   =A00
> >=A0 12 Power_Cycle_Count=A0 =A0
>   =A00x0032  =A0093  =A0093  =A0020=A0
> =A0 Old_age  =A0Always=A0 =A0
>   =A0-=A0 =A0   =A07999
>=20
> SMOKING GUN=A0 =A0 =A0 =A0 =A0 =A0 =A0
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0
> ^^^^
>=20
> I suspect your power supply is good enough to slowly spin
> up your drives and get them talking, but when you ask them
> to work hard, especially when writing, the PS voltage dips
> enough to reset the drive.
>=20
> Look up all the power consumption specs for all of your
> components, and add up the *peak* current
> requirements.=A0 Make sure your PS can handle it.
>=20
> HTH,
>=20
> Phil
>=20

Hi Phil,

I was under the impression that I had an adequate power supply, so I ch=
ecked all 5 drives. In fact I made a table to compare all the smart en=
tries. The differences I thought were significant follow later. I hav=
e the full comparison table, and the original smart output, in an OpenD=
ocument file - which I will attach to a separate email (in case it gets=
blocked/dropped or some such).

Note that Power_Cycle_Count is anomalous only for /dev/sdc, so would th=
is suggest cable problems?

I am not sure what to make of the other discrepancies.

Note that sda, sdb, sdd, & sde were bought and put in at the same time,=
while sdc was only obtained and inserted recently.

sda sdb sdc sdd sde
4 Start_Stop_Count
720 716 16021 65535 713

5 Reallocated_Sector_Ct
17 42 0 1 79

9 Power_On_Hours
12505 12500 2960 12405 12475

12 Power_Cycle_Count
720 716 7999 719 713
=20
188 Command_Timeout
1040 1 1 0 4
=20
189 High_Fly_Writes
1 0 0 0 0
=20
Only /dev/sda has any errors logged, the 6th error occurred at disk pow=
er-on lifetime 12416 hours (517 days + 8 hours)

When the command that caused the error occurred, the device was activ=
e or idle.



After command completion occurred, registers were:

ER ST SC SN CL CH DH

-- -- -- -- -- -- --

40 51 00 26 52 c2 0c



Commands leading to the command that caused the error were:

CR FR SC SN CL CH DH DC Powered_Up_Time Command/Feature_Name

-- -- -- -- -- -- -- -- ---------------- --------------------

60 00 a8 97 51 c2 4c 00 00:07:58.408 READ FPDMA QUEUED

60 00 00 3f 52 c2 4c 00 00:07:58.407 READ FPDMA QUEUED

60 00 00 3f 53 c2 4c 00 00:07:58.407 READ FPDMA QUEUED

60 00 28 3f 54 c2 4c 00 00:07:58.407 READ FPDMA QUEUED

60 00 18 67 54 c2 4c 00 00:07:58.407 READ FPDMA QUEUED


--
To unsubscribe from this list: send the line "unsubscribe linux-raid" i=
n
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: RAID6 data-check took almost 2 hours, clicking sounds, system unresponsive

--0-856331383-1302815684=:79604
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable

--- On Fri, 15/4/11, Phil Turmel wrote: > From: Ph=
il Turmel =0A> Subject: Re: RAID6 data-check took almost=
2 hours, clicking sounds, system unresponsive=0A> To: "Gavin Flower" nflower@yahoo.com>=0A> Cc: "Mathias Bur=E9n" , nei=
lb@suse.de, linux-raid@vger.kernel.org=0A> Date: Friday, 15 April, 2011, 1:=
16=0A> Hi Gavin,=0A> =0A> I think you might want to investigate your *power=
supply*=0A[...] Attaching OpenDocument file with full details of smar=
t output and comparison table. =0ACheers,=0AGavin
--0-856331383-1302815684=:79604
Content-Type: application/vnd.oasis.opendocument.text; name="raid-notes-20110415-smart.odt"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="raid-notes-20110415-smart.odt"

UEsDBBQAAAgAALqljj5exjIMJwAAACcAAAAIAAAAbWltZXR5cGVhcHBsaWNh
dGlvbi92bmQub2FzaXMub3BlbmRvY3VtZW50LnRleHRQSwMEFAAACAAAuqWO
PgAAAAAAAAAAAAAAABoAAABDb25maWd1cmF0aW9uczIvc3RhdHVzYmFyL1BL
AwQUAAAICAC6pY4+AAAAAAIAAAAAAAAAJwAAAENvbmZpZ3VyYXRpb25zMi9h
Y2NlbGVyYXRvci9jdXJyZW50LnhtbAMAUEsDBBQAAAgAALqljj4AAAAAAAAA
AAAAAAAYAAAAQ29uZmlndXJhdGlvbnMyL2Zsb2F0ZXIvUEsDBBQAAAgAALql
jj4AAAAAAAAAAAAAAAAaAAAAQ29uZmlndXJhdGlvbnMyL3BvcHVwbWVudS9Q
SwMEFAAACAAAuqWOPgAAAAAAAAAAAAAAABwAAABDb25maWd1cmF0aW9uczIv
cHJvZ3Jlc3NiYXIvUEsDBBQAAAgAALqljj4AAAAAAAAAAAAAAAAaAAAAQ29u
ZmlndXJhdGlvbnMyL3Rvb2xwYW5lbC9QSwMEFAAACAAAuqWOPgAAAAAAAAAA
AAAAABgAAABDb25maWd1cmF0aW9uczIvbWVudWJhci9QSwMEFAAACAAAuqWO
PgAAAAAAAAAAAAAAABgAAABDb25maWd1cmF0aW9uczIvdG9vbGJhci9QSwME
FAAACAAAuqWOPgAAAAAAAAAAAAAAAB8AAABDb25maWd1cmF0aW9uczIvaW1h
Z2VzL0JpdG1hcHMvUEsDBBQACAgIALqljj4AAAAAAAAAAAAAAAAMAAAAbGF5
b3V0LWNhY2hlY2RgZChoZ2BgCOFlYOBgBDL4gTiAk4GBRZcZyoiBMbphjN0w
xmsYQ5oFyvCEMSphjGUwxjUYg5kVyjCGMRKBDABQSwcINatNbkEAAACLAAAA
UEsDBBQACAgIALqljj4AAAAAAAAAAAAAAAALAAAAY29udGVudC54bWztXf1z
mzy2/v3+FZp0dqe9W9tCfHs33XEdZ9v3bdJe22n33nd2PATkmC0GL+A4+e+v
BPgbEoMxll11Om0CQhw9OjrnSOjR+dvfn8YOeMR+YHvu5YVQhxcAu6Zn2e7D
5cVd/7qmXfz9w3/9zRsObRM3Lc+cjrEb1kzPDcn/gDztBs347uXF1HebnhHY
QdM1xjhohmbTm2B3/lRztXQzeld8JQifnZ0fjwqvPh3ip3DXh2nZtWeN+93f
HBVefdryjdmuD9OyBNTVx4ferg8/BU5t6BHUxxMjtDekeHJs9+flxSgMJ81G
Yzab1Wdi3fMfGoKu643o7kJgc1FuMvWdqJRlNrCD6cuChlAXGvOyYxwau8pH
y66K5E7H99jfGRojNLZ6NXh82FkjHh8yoDFHhr+zbkSF17tXtHbvXtFafXZs
hKOMPtEaN+Rm9M/Nl6Uu+ONd30XLrkFl+vZk52bGpVef9zxvISp9IB6gkbgI
QqkR/75SevZi8Zlvh9hfKW6+WNw0HHOBuDdOA42UExqkRA0/UjVdKD4FIsh4
ADXi24vCgZVZ9T9vvvTMER4by8L264VrthuEhrtExqedkNlSueHjieeHC2CG
uxtM0ltoIdsoHDvZw53enRd98C0rtSgRR2yQoU8GXu3RxrM3a/bwZX3QG1Gh
heLa2JmPkkXZpDn4aYJ9m7bEcKgi1MYBAY0ohzdprjy9bhP98dNu1VGF8Kzh
Zo0bg8MMAjFMw6DfbdB7NeoSiNFL3rTiCgniEYDN0DfcgNZLDAy9ldRFeimo
R71Xo6JGlca1EDtK1C9wwgaRD/nWsE5+ufgw96LxCAwaiwtD4k1rQ8PENQub
TvDhb7E1XFwG8e8UhcuLLzYxrZEkoEfgGAoXgBjAeeGx7TxfXvzZmHjBXzdL
xlcvGi/X3/amvk3H71atyzvLxw3L893IeVxedPHD1DHW78fP1h6wSyQghmDs
Wdh314pM7NAktnJoP2HrNeE2m5S37S+J5ntjI1WyR8O3I5V/Rbgr/G/j+xT0
iLZkyrVSZgeRgucgxOPXZGpkqVFy3ZiGHtVdsxbVs9Cv6N+1FvRplcLifYnk
8XifPxX9VpuQEYf90MZBUnhmW9TjCUqdmCGTyBxHS4ZjP5AhMzb8B5vCMvSa
PzGe1GZ2OKq5UeRmODPjOYgasiLXa0LWW6likkDAmY7dDWnji9tCJ9cT2VFd
E0VzAbePndp6AQHqCP13bkk/li6pUJcE5SVJZUkR8gua3vM135ttSEmubIs4
tt3oxgjbDyPSr7CuIXUpZNTtofeAwxENDYeGE+ClPixvFFWHDOFN7DibGJNL
2+I/0t9IMFKbq6xNbH8s4cSw4gkRrEM9ahK5eO/5xJTVHDyM2koiDnMMAs+x
LfAGRn9Wi/kxJq7n4tXLoTfZ4eF7LwxpZJReMC9Svx0HqbLER6UrqV6dkmYI
fwJKunmxXJ38/SSAebVcBUiJe6n/ofT725ZNmRi+8eAbk9H8BrlAV46iX2or
TRogOGjHy0nBogmLp1ebQMSkwfq8i03shsto9N/TILSHz7WAdDV5wYxgP2/f
VisamYFRcuPes54Xv9B3gmjhaBrgWuANSRBmPODavY+NnyTsDf0pjY6iEgH+
zxS7ywhs+2Jck2UHE8d4rnnT0LFdTPTwEZOZGlGm6HYMz2fHIY2Ko1jaiL0q
68+jxf1qIT/uXclVvBQW9Us6alHoGP2bhJHr4Wl8bUuThIu1R5OQKLM0iSAb
+R74OH91vL6VlA9qZGKPjRBbNELcrHOEjciCeLP1htEr2W/aagoxei80RNgQ
jL6tFkwM16VCoeXs1nCmuBY+T8izRLNoJyR9OYk7KHV0fiJNiIp+vnoDWv1+
9/PHu35ncNu66SQdOKE9uSHuXg2YI1t+GxoWfmwElrGUfPdn5e83wvfbG32H
Vpse8UjYqi3vbOoaY4DcFwFE+X6DPsk/1HMExCyoIb+J3d92GRcnB4hVVENa
N7p2eEB+qxwQXBSQ644iFQVkrTSx8xtXirkbdFGWVpaG8feyXEtpEnVbP5iT
iaPEUeIonSJKv1eG0rbH2NkviPmmIfs2abkMIICuMRt0SRMHHd/3/EGXzK+O
rAvfyKRMECADUiBVURSoKgyIIgi7BP8HlwJJoiTrisCCLILMgBSaqosCUkQG
RBEEFrpFVGVVVNAuc/fDA1KWFEWdSGREkKZDAb0yNTtF5yGC3sR2B3eTQd8e
s+A1oM6CkWTBc3EklkiwYIrYQILrRNlI7OMYXkbiFB2CBHqh4YeDXuhNyOWp
GzLQ2QJkQeVUxIIUjGAhsDCjghoL8wdBgYiFsB2KLDgHRZZFJnqltHGyj4NQ
hZenlafoImTQxYbjeCb9jj/oYTP0/EGb+4mFFCwMQzZiZgkxIAQbWsGCDGwg
wYSvLG147OUdXhbiFJ2DCnoY/1x+iWChr1+BuRopNF1SJU1mYQAyAogmaKLO
xJwKqiz4KQSRjBTIQvDMioYQNCSViXCqNED28RearmkQai8r6yl6DR1882bY
H3x1B5+8qR+w0OMaCyscApLZMAjMoMGEv2BiGR7pChNgMKIa0pkNlH0cBUFD
fRmNU/QSAoy/Vndx6D/zjxN8eYEjwZH4BZHgX6zXvAJKJg/tZ5Pc426Bf7Nm
+pu1zsJGU1Vn4vsQK4pxXljwD9YbHkITQZd4BXuMBx8Na/DR8cyf4Ky6nAdH
54IEG1wVtAvplivF6SHB5w7rnkECHdeqhV6N/Bd/tT6r7uaKz5HgSHAkuFvI
5xZU0I1OoMbW4M41Pd/HJguLSlBnIS5jIUDlRoAjwZHgjqFqx6CBtjceG2Sy
QAnT3pQFr8CG3gtQYkMMJqRgQQaOBFNIsCADG47h5SD2NB2DDj7ZD6PBtfM8
+EGz+jCxh5WNj3wsyMAtAEeCI8G0V8g9XYgqWT9jvnESzkKHoGX7Q8ebDfp4
PKHZl6Y+HrSxw4AyQIWFfdSiDN7e2G7jxngCgt6Q0DsGhIIKC/5UFFagURqi
xgQ0bFDotBVo1IbEQugBVRZMvAjXlUZlQmkUFsgSorQCjdZ45cyCk5yd6BLY
cDSBPWVihsLEWTHU2UAgIAABC2MViizYLepmCCiQFVDQLokRqnAwBBSFgsKE
BRVZ6BvqXOaqwgYqZX0m3devzK3Ky6icpk+RwSfDt2YGcSiddnvQxUlCDBYU
gImDhxg6e5wNP8vS2eNsOFmGzh6HTFCFGDp7HIosnPlxvmePC7oK2lOfproc
fMMuzdCRnCbIQOfzxeEVJECy1hoXMC8v5GVCSg4PC1KwIANH4sS/p5yAx9DA
1+GQpstdbsulxc6qz7n2cyQ4EhwJ7hvy+QYd3F3dtAbtbjs5fpYeBcJAjyOu
+0whwcTSIBNIsCAD9wzcMxzWMyAJApoBlu7NpWtMrJwwy4bmi6Iu0SVoWZb4
YVFLKWQoKYKsQlWVBZWFL89swIKgIor05HZNQuQHBiRiAxcKiAyRBqEiCGd2
eMpeB9GSMaQriiAiTdBf+Z5ymr5FAH0vNJzBl4+tIGJ+kDtn1f17WVFiRAVN
1Fj4nMcGIiJBQxYlnYntsmxAIoiSJIuIie/xjCCiyxpSFMjPJVxIoeqCRFwJ
Or/NuUhCqy6kS2YqZ9Xr+0khiiQGZ2T3EhuQKJoEIdRkbi7nUmgSsZWI+BAG
ZGEDESSpuow0Pg9ZhF2CKiqiSuzJ2fmP6FsHUIBnmnQzlQWMEFh28BNM6Kno
Nc8Fjj3E9PDbErUhvulOx/fkFabnTMduUAsmhuti6/Jivy2iggJGdIkOvJUF
FVjGcwD+ArT42i67y5NtyLXlnQYzzbv1QNRfAfjiPTzstFeaN+eMm/P7KTRn
2yquXsmWoRcarmX41sWHNyAYG35ohg6oGaBh4cdGYBl/fvMErb8upXq9nkUt
cl2CAEEB1uhfBfgiPYHjjydNGShSjbRgZIQ1x3anT7UHd/ov8Jamq3bA/dR2
rHf539v2Js++/TAKwdv2O/JeiMh7wf0z+OhPTQxajoPd92AUhpNmoxEJOSb2
2fOcoB4Qs2Xioec/4LqLw/zvzv/E5eUl6PVb3T74eg0+315/7d60+p+/3oJe
px39Twrkr/XGs7ADro2x7Tw3t3aESheNDz1sPBghBh8N3zfMqWUAlUBVFxAY
Rk/lf+cVfiSaD6JXZ7yzL8oQSoLW6uWvvod9m2jFbTT0tusXSf3y9xvh++2N
nr/ya9sfU3IM+I79wPbcJmi3RSl/PXcB9kHbmBimHaYAHwkJ4XsBqu81Bb2H
ZDTcP4c4yP+mjBMVkk6wg+2Xq+Tln93l4LYMYhKMAIM/iMIDC4eG7QRgGuAm
qH0Dwcib/Su/WK1+a45hqhCICKEVq3b+22q9DXqnptVa7R7wSdOj9xboty+R
xaGnxKVKTfvt2rdBa+IDQQZQbSKliRA1agK4/b9ev4A639AxH0wn9OTS6KWt
R9IB1EiDGumNqBtHRgDigibRqXvbIVpVL+NdHZe+yKrcwHU7raukRVdRn+5j
5OJ6qBM0HKc2woYTjkCAnWHNCAIcBGMSc5Png5CoRjB1wib41ur1OldVtPof
2KViJW39TqOBoJm/mmQDbTRWAQk3HGyGVMWD0Ainq8PgLXzS0Lv4VzKsG5lP
GuS/R6JGRS1OVHmeH2dEh01vPHFwSOY7Mzskc4MQYBrrFFDlgkK0pqE3340M
rigk7QUki9FQZGRRbYtUDD9hc5rWN2s8jLepBhGudlx/hMGE2jJvGsTaHKsw
QY0Kv4Cyug5c7TJA/rreilzURGEyBEFl8txj7AJ/6hbormjpFtDpNSD6MIdy
oRj5K9wYXfNO3xQZvAWyjt4R2EzPtYICkmcM5/wVLRyJjYMscdckh0/q/bvE
jsVKvgTMHo+xZZMw8kgjedO4eW6DzL/mnq46oXrTYIJdayHXikjTCfnHxbPK
ZDHjI2+ra/y80cHUHxokaAlMw513QSGjWrQTFjbpCC9ve+4jfjZc0v6jykFe
ThXvsSwxNqLPFaOxdGGCcBEFIBBCcdWT9YxHPI9fo5F6T6fWGJCwDNMVkcpA
iRdXA+ORvBSMyfy0SssQYT+HwaDWiwiCIydUJACKV5Ad7+GBNmY5LUif79Fe
EVb7ZP3xIyjoPDD+NvUnHpl8filBlN6Izmu2Y6X8NfmYmk9iykmoOiFGnEpG
e2rNU4L0KE54B8a2S9xjEf/eeQrjt2614uCNIBNyfR/RV0xf9cKv9QDapxm9
drqdi1+4+TolHlwCFIdrJo9U0ovi/6MYf/L2eIAn57s8A/rpyfecY0lzjaND
zI4tRjTji1bx95KgqPtshaFv31O9jCXphf7UjHBZrFm5ybKmAPO/5DsZLaTP
exNs2kPbBFsvpTM40B/5OBh5jlVkHeLz1RvQ6ve7nz/e9TuD29ZNZ2tE6HSN
7EvrH6krv99bX+464MfXbq8P+p+6nd4n0P/fb9uV0Dny3berVr9ztTRPPz51
bgfXrc9fyMVu68cgqqy0FdNUUw66xiza3ZOw07p0qTytYVHUM0z3B8L2WQzR
bF/X069DJXXh8ZuPa0PDdlbWPJ0Z/dCaZpNqqVfnhxsVBm1NUJGomu0O7iZR
Wo30cDCOBjPar+a7nnKmRUm4FBhsaRJK1Ob74aAXepM4p3lqMEYxEVG6rqS0
8aXrEKVj8tWxBkS3U5/JjY6KSsJHJv7IcOhXPZqjKz42ZtDeBgnNQUpXnNwg
iQcbUIJaDjIqmabhny8ZGe1lIwPVDGOiZGFysMGk6ZIqaXJJOqODb3TWNvjq
xhywVH/zwoiC2nbnv3g9w8qUOqIEJEO5MD5U02PT28Wh//yKpRFKGkQpVvno
1pcimehH+9l0cAYUyq9idDOSpmfAkbPZmXAUGDHztcK0uK80JUlLFHxwh5wS
1JWuG4WwSMuOmYr/S8ZUl/Jdr8KYFohmU1LCZTrcnIoB9WP6FSgV0o2tPEjZ
aBj55jKZc5wq0CgARXaWD0CbjzLGhSKnX5czxoW0Xb705m9n4yiCR+oh9JlT
4Cx8xAx8pCMOltUD5AtBk3WW8jIUiuKvjBEjZUAlaMeDpPj6QPa5oBtolORm
q0CjiCnNOuwuc46bsTh0PkFY+hFP2/5WnHuYdGFRRsOzrrOqIakHm5QVoiM5
Y6mtEu1YP5WkCDRpvPzMGPWksFmQ6ovAssU1zQzPTgqTJVG0uk8w8STwi/ew
3OFdIEykW1bjmiJb1gQKeJts1XVI1abnhobtBsBznWcQjjAYe9HuU5PuRB3S
XRnRJrqgQNgRF4n3mnTB5XwaQyZ3D3YQYh/88anzzwIbtlfqvab1Jl/sgjIr
7rVJxUlUEDuBMiu/XVYekwPKrL39hWL9TDTcwlR/ZqVW/mm1cjoVK7P2K1p7
zAdoUM9Tat3tRd2H0MQO1cR4oPklakqfakr8dX7faqPFR7qkknwEswMwxkYw
pdOAoe+NY0InMQTvAcVm4tsu3f5sFGB6XF1ZfxmNmuNxs9erB0EAZiPyanB1
dUnplu/BaHQZ0S3fg/H4Mtn/8L6AnexdBtiMxSVvITU5jk2u1MHnEPz5P1Mv
/OvMNyZB/CMwhhQ9Sa+rJJKlglTyPX13/iyx76+wU8v5TvFjREIVauqTfZfk
ZyKTaUwDbEXXk23TicDvo2uJz6Bb4414tx4pYltOkY1p5TSjFXXnvA3Jzuho
S+1C8PmQIQpI9K/AJoK095KRToYlcRDEjBNbSyzi1adyaq7VwNbfkj73QiAL
gIRKSAEyAiYC0Kyw33bZwJDY5AA4xPBHW6i8HZS0xH4lMQoJJ9b7FRCvkVZ2
05YuFg6SVjSSmGRwS158OOWgfxevrm38yb5D/5QjlAKpUhka0FWqYESvJBNk
JPSAsAnVpqzVJagtZYvoVdffyLQb/M9d564I1SlbMPJXHCYKv5NgarWCicwJ
hrRIMIk5wQQNKOrxBCvq92Xu97nf/2X9Pnfw5+HgE3el7mR85bosiRV5BVED
xNAzKJgZ+1GFOcGSrpSZE8yEQN058ihfsKIOXuIOnjt47uC5gz9pB59rBo/q
il7xRHm3GfwRBNttBl+lYLlm8FUKlmsGTwVTmHDwInfw3MEXXNPmfp/7fab9
Poydhb6LTZb0uobkat2rtrNgUrWC7bTiUKlgeZZCKhUsz1LIAQQr6vcR9/vc
7/OJPXfwJ+3g80zsJaWuI53BiX0kWMV7Bnaa2FcqWJ6JfaWC5ZnYH0Cwovur
l6fN0Y3QQdYBN0U2Xd9Ox8sm9skrBlc4MH17Enm7TXTodvVkj+fmLYFyfrt4
bNgutbuLOr+QAIRat7dxlLFy42Nr4A0HQ9snL43scH7p3wBhWWFnfsqXl7Fp
nkr/mR6P508ndL8oESk+vhiH71IVQYd/2rpOSXkCEuVtjh2lCxSwiHsoRXIY
YbCmHtFhgKXqyALh3rfW7RLvm8+3lDyxcqH1z/UL7btut3PbH/Q7vf6g12/1
7wocTZ/aAVvgR4zzl682Ptx64YDitMfxiOtybPPujiPHNuHkOHJsE3OPI8c2
MfbwcqSNx6FjPAT0lF/4rqT4Mp6Y0FNgIzMbRC+lJxtODDd4DywP3H7tk0Fv
WLXoqFg/ssiUAeENo6lhgSnV52GqsbEDMIlJqYCYl3jGOZ28j86DJ9FsvIcd
JocGkjmeYxQ5Xr+IU8j/TCP7TxEBUnK83Oev51g5XhK921w25qlfftXUL8r3
G/RJ/lHgWK7TS/3Cc7xUk+NF0ptQ4zle8loynuMlXzU8x0s5QvAcL3t0IM/x
klkhz/HCc7zc8xwvPMcLz/HCc7ykWwae44XneNmhW3mOl/174MxyvGTsfOWp
X8oSg6d+4alfPmy+KzLl5eR4ycplUnmOFwFJoiTrSvGv52uS8iQvm3sIzzTJ
i1BSVqCSkrzkPlH8cEleJFQOMmeV5EUTNFEvKzHQ2SZ52Su1CU/yMkfibJO8
FDG6PMnLOho8ycsSizKSvJzNWfyHTPJyYmlN9s/wcjZaUTTDS0aPp+yujq5X
kuFFWMnwojRE7ZgZXrY3Osc4HDEzFMUHAhJHHSfDS1bSm2NmeNljdYCneElg
4CleNhE54xQvBeb+Z5ziRYaSIsgqVFVZUAvs7TznFC+iJmqyKOlqIZU51xwv
iiaRN2lyAYdT9FtLOTlebr24oiD6bF3N/tnDcyhXtvMFYEQ3J0Rb7JyoifWl
I/+j79F9dyul38fbxZd8kbDAlnHOOeScQ845PLYcnHNYJucwkWNzA8cvS0Us
iYVY4GCWY7EQOd3wV6Ubyt9vfhO7vxXYipJKNywwo+J0w1X7fyZ0Q5nTDXNb
Mk435HTDX5tuiCR5bX/y1h55mwScvvdAVDao16tDSIZ/ouF1MlySY5dOi9Gn
QMgZfZzRxxl9h+sEzujjjL7UHzmjbyEPZ/SxyehLKtxcAuwclegnc6Ifg0Q/
zujjjL5dXsIZfcdm9GXs3que0aepuiggRWSE0JfFy/p1CX1Qy9CVrOtVcEsE
BaKSOKAlUfpyb3g8HKWvJNUpgdGXtd28ckYfgkhGCpQZYfSVxBsudy+ornBC
3/5DqBxCH9SzHFTG9UoIfbquH5rRl4WHmsFEybpeyYgp8MGUM/o4o48z+l6F
gjP69mT0ZYVeckbQXgWjD2krjD61IQlHZPShDJpaCg7V+RMtYvQpx2L0ZZAc
0RFdbPHVAU7o44S+X4/QVwCPMyb0IaiIIj3MR5OQWGT/6Tkz+gRRkmQRiQXi
s7Ml9GmSokBEYOF8vl3l5zkRM3kfeXMivrinEcgpSRDlZN0udfQVyIH4BqCl
zPHWhSyB6XBpp29PTXceKeJTKbeHO8/feEguZfpRvOsTJ06xXJeDUyzX5eAU
S57WsTiXsiQKZYEYh1Mod3mCUyh3Nkk7ZWxs3egFpp48YyOnUM47aJ1CKcMm
QpxCmdeScQolp1D+2hTK1HU1nrExx488YyPnd3J+Z+aPnN95RvzO0pJ2cdon
p30+LaaBnPZ5IrTPDk/kyPmdnN95IDE4v5PzOz+kWYyS+J0Zezmr53eKqqyK
CipAHEkTlCds3JCwBH6nmNH2rOtVUI0UWRZLIuudH7+zJOLreWVsVKAsqSoj
/E42MzZKe/BfOcFzBYnzzdh4cH4nz9j4ukfm/M6qVYPzO4tDUchkcH7nvvzO
jGbKu/May89ICNczNqrHzNiYgY+UUb6SjI3wqBkbpd2PjqgOksKrA5zfyfmd
vx6/s8D+wjPmd1JipwyRBqEiCEVOYzlrfqcua0hRYJE53dkSPJGk6jLSCqjK
qfM7EzQ2N3WwSPvkaRzPk3q4FrxzjuG6HJxjuC4H5xhyjmFxjuEBUzcW2EHE
eYe7PMF5hzubqZ14h9cdpUCcy3mHnHc476At3qEscN5hXkvGeYecd8h5h1vL
PZx3mOPH0+QdspJXMmPpi9MRDyAUpyNyOiJPN8l5h5x3+OqPnHfIHu9Q53kl
Oe/wINJw3iHnHf4CvMOs/ImV8w4R0nQooCJH76VJyomHGxLuTzxklAJTUibS
kmiH2RlJM64fjnaolsThPSveoa5pEGqI8w4zIRKQpHLe4f7W96x5h0USPGmc
d8h5h5x3+Doa58k7LJR8lfMO9+QdKhmRhLy9b7Q63qG0wjvUGhI6Ju8wC4cj
RmAUHwhI9HCkvJIZRgKVRwSpcnWAEw858fDXIx4WXxXZ3HZxznxEQVZ1RRFE
pAm6WIh3d758RFUXJAIPKrBWcrZ0RFFQRUVUBcgTTu4sP084mclWWUk4efjk
jbSJ0vY62WlknixbeLFq4VPy1xcWXloK39klT2nrPlpaoUSikRdsxzcCnSTp
WYJvTwh5wk/OuuWsWybk4KxbzrpdeYbuIbdN3KS/L3+796zn5W+WZ04p7ahm
ei5xHuGH/wdQSwcIYt60Y+AcAACX+gEAUEsDBBQAAAgIALqljj7fPTwx8wAA
ABQCAAAMAAAAbWFuaWZlc3QucmRmpZGxboMwFEV3vsJyZvyCWYoFZGiUuWq/
wAVDUMAP+ZmS/H1ditKiDlXV0fbVuffI+eE69OzNOOrQFjwRe86MrbDubFvw
yTfxAz+UUe7qRj0fTyykLalwKvjZ+1EBzPMs5lSgayHJsgz2EqSMQyKmm/X6
Glva8TJiLLeUqCNW02CsX0Hh6g6qsSKBmjqKcTR2IVoCbJquMpAICYPxGsZL
u+PsY49+xckXfIGv+LOmJ+388uwM4eQqU/AKrQ+dInRy+DVN/tYb+grn8H34
aiLV4yf01PXmLiP/KoN1s5X5MTV0peplmbSpSv9dtfXMYf3iMnoHUEsDBBQA
CAgIALqljj4AAAAAAAAAAAAAAAAKAAAAc3R5bGVzLnhtbO1bW4/buBV+768w
FLRvsix7ZjJ241mgs9h2gQRdbLL7uqAlyuZGEgWS8iW/voc3iZIlWZ6ZJEWn
CRDAPIeHh9+5kmLe/XDM0skeM05ovvbC6cyb4DyiMcm3a++3Tz/5994PD395
R5OERHgV06jMcC58Lk4p5hOYnPOVJq69kuUrijjhqxxlmK9EtKIFzu2klcu9
UkvpESVs7HTF7M4W+CjGTpa8jbloM35lxezOjhk6jJ0seQFTd3pCx04+8tRP
qB/RrECCtLQ4piT/vPZ2QhSrIDgcDtPDYkrZNgiXy2WgqJXCUcVXlCxVXHEU
4BTLxXgQTsPA8mZYoLH6SV5XpbzMNpiNhgYJdGZVvt+O9oj9tgeaaIfYaN9Q
zE3zLuLx5l3E7twMiV2PTe6DD0BU/3x4X/sCy8auJXkbUEWMFKO3qbnd+ZTS
SlU5QQeoUnc+m90E+rfDfRhkPzAiMHPYo0H2CKVRhTjNukADvjAADh/vpZta
biY33Sv5NmC4oExUiiTjExSgM6/CayeytD+8JNWyblkcd7KCOosAQg0c3d8T
fHjTyD/D+C8DxVS5NOcL0bXGp18DSfNlioMgNlnWyeywI6XgSjCUc+lEEDCS
ZGQBCnyq0PGlFkqolgJ5YR5ADhIBjZM5i5Mp/PAebFFIKBSEBEXYj3GU8od3
Opir4Yn+LSFfe+8JZAa18OQjZiQJvQnEr2XOSHpae39DBeV/b3PqUS8Ylv9I
S0ak+51JrSn1dBRTlqvct/Z+xdsyRU26nutvcQ4agB9nNMYsb7AUREQQ6gk5
4viScu0tXbv3IdUYzVCnZnvEiPKgC8r9iP9Ev5eTj+AcvXo5PCNU4icucHZJ
p6DPjcy4bjWs7jFOUJmaBsRKNjpuGSp2JPIsr/ntFwwcmgkCDYsswyu+A7sf
fJDPsfCPa282XUSgZwfx1CIKqBE+lFTs8wJFUND9HWXkC6iOUsk6vx9k3ks1
onNWyEFjpZ6xdsg0sKSwjwMRO1+3SAlKueMFBWJIIeTio0mS30eloHINcA0S
Y6pZUVrskF1AqbFhGEH7wQWYXFiKrAFSNxkvay9lvtg03IDkMZaJV7aS7mas
klZHSH1gaVpw6Sf9alfsUu+z3ZQcAwy5tKpaPKIpheZEsBKyakK1Rpx8AU3D
eSHUWIrybYm2MIRzNRDRMhcM3OGf/6i2jwUUOv8zZASluhbo7FLK9CGhotxK
NhONcEv7cjxaklnGUnKad4iUzU6Kjz1CK2qH2IqmBNegNqJqTKhVVvAG3QmA
252KHc5VLvNTFEP+9JU2UgewfUaqHYz0uqLMI1FqgQcgQwGDrYMFLruldSc/
JhCcuVwEStttWMdM03ELwLMOmCd4l2O5vgrwNR1QrmldqZnev6qTqmUrVxtc
+KVc2fU0bLNI2/0YzhDJfdnoWx+cnzEVJd+1WJ4RJ7p3c9JZil0X0kfKDWUy
LKTPQRYHB0pRwaVDP3dhn9FDa3EYaQXoZ4wLX9AtFjt5ZpMBeGlhd0Ht1x8h
nGLEYq83T1jzpYhDsyVjqY6sc3n/wih2QrpXHAxU1xF+tyq5DFuX4RMM/DGf
/bGh8alLrUsZLUMM0g1AVsiSezNXJbce31Ah5DkGqnE4NySFsSrFuSrFKD2g
E7+UWgbyRniWOG7q+Hla7HcKuDaKpZDaeS44TZchIDMXKTo5ppq45Oc4wpNt
PGzf0dt9D0XnKfsY8NdUihwIo0dUSJ95QfRAF4auDJE6DvpCRN3L6Vsj1Q/y
KoUriqro9lJp1h82PbVUj+lLRgItNRwRxlTAepql9k3urGLO9IpuBIx2mZ+h
RT6+oPWIkjdovatNMW4nMqE7h+9v4ojXbeXszNEesCpSTvTFyf30Znlf947i
VIC6EegPGw0uzg7vpsvlsj2dke3OTaGONoMHoHFW+IlS8X8rfG8rfJKdmMzo
j5Ai9I1mZ/GTbJM2z3+j0cZXfLvzVn/XtfFntIC9AF9VxPR5NCXbvPInI+bP
kguSnHzZpMOiB+jfm/i8XCk7YOmKa29D07hRWTTBVqY+clV5FMNV2Rr2JiEM
u21kOCbhU+zTMu2oDt0eRGgpFIYp3svTUtgybaO7u9AfhLd/9S4D3WgP1JTx
Vmh1Bz2zn2+k+bCR5t/ZSPNnGOlmoIm7znbtA86l1u4623ZLb3d+X8X6i2Hr
L76z9RcvZf2nmfl5ZnyekR5prOrQL4B4t5Ekx8Qlf6sT7gZFn7eMlnlsryzf
4Dv5V+FdoFg/AZlNZzdLc3rT91RqbAbHtgmnKYknb2bqj9VBfz8x13JWCWcx
kqEtfs51vnMrUn3Sa3rN22suIayJHnf1t78OE7nk6o5tyJGvUXbYHqO38iNO
SE66Dvz2uk21IDY8zwX8W1O8FqOKY8Oum5hW7YV+xtcflOWgVVBeTpi57c7S
JZlW3AdXVp+BsP1qhDZAVv2X/ELbJbbFYmSrwYSmKT3g2N+c9DUJtPAOkp26
AbVv3yMRmXcjonmsVyleLplfMVKLa5BavGakbq5B6uY1I3V7DVK3rxmpu2uQ
unvNSL29Bqm3rxmp+2uQun/NSC2vQWr5mpEKZ9dAFc7+R7FqklwAcyowhwND
npBtaT4QVwTfnAcTSoX8PYSlfqy2R2mJ5b2kHrQTuV9fmKs3Me4cfZkpH81I
efYtbXXaGKUhzuM+BUm3gla8RKTWoGuZ3qtY/cRPfcN3vwB0oWOE1CikOBGG
RvKIqffzsqdw3jMqafUzRvmuQr64jXxLsAfgLVgbncC6jbPYhyILvQ6m1jFe
UQ4kls/N5zP7LcMSdubGZL6c3g3s0SwCEAqfwiE1F+ZpsHxAzRARXvujbs8H
3dawROlskBmV+h5dtV4Lag/0M3SsdiM/yNdvWQ0Dx/bjjkFjNp2Fznch++TL
32DYueKXPOEs7OBBiXxY1cWCYnn5r82tnUCPM4hWa4b6ltee5M0ViXvt0WVQ
u6md+ljafHNjxhL1Ba/9uR1gdcE5M8Gs0wS9Dxt0PNTaduljFPnGOtpHNy0F
m8qcY1xH5XkYGkKGeCWiMoQZlJIawdm+eHPN2RG+GheTsQqbz06Ny1bM7LVL
QgyhUeUgd5Vp6j0EO5rhYIv2JA/4DjEs74uyjMIv9dwa6AeAKYCwjdU/vs7A
81kYzm7CW58DlGJKY2HKSrWcWR6KVWBLTtFygabx+zdkvjO7En+RGJoJEi2d
Us1UnOJIKJjXXlQypmpueGu1qPkfJjRxpag3ei1OPXa2A6tzcGba2jtaThB0
/7e3h/8AUEsHCH6+xAePCQAANjcAAFBLAwQUAAAIAAC6pY4+xEvlqeAEAADg
BAAACAAAAG1ldGEueG1sPD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0i
VVRGLTgiPz4KPG9mZmljZTpkb2N1bWVudC1tZXRhIHhtbG5zOm9mZmljZT0i
dXJuOm9hc2lzOm5hbWVzOnRjOm9wZW5kb2N1bWVudDp4bWxuczpvZmZpY2U6
MS4wIiB4bWxuczp4bGluaz0iaHR0cDovL3d3dy53My5vcmcvMTk5OS94bGlu
ayIgeG1sbnM6ZGM9Imh0dHA6Ly9wdXJsLm9yZy9kYy9lbGVtZW50cy8xLjEv
IiB4bWxuczptZXRhPSJ1cm46b2FzaXM6bmFtZXM6dGM6b3BlbmRvY3VtZW50
OnhtbG5zOm1ldGE6MS4wIiB4bWxuczpvb289Imh0dHA6Ly9vcGVub2ZmaWNl
Lm9yZy8yMDA0L29mZmljZSIgeG1sbnM6Z3JkZGw9Imh0dHA6Ly93d3cudzMu
b3JnLzIwMDMvZy9kYXRhLXZpZXcjIiBvZmZpY2U6dmVyc2lvbj0iMS4yIiBn
cmRkbDp0cmFuc2Zvcm1hdGlvbj0iaHR0cDovL2RvY3Mub2FzaXMtb3Blbi5v
cmcvb2ZmaWNlLzEuMi94c2x0L29kZjJyZGYueHNsIj48b2ZmaWNlOm1ldGE+
PG1ldGE6aW5pdGlhbC1jcmVhdG9yPkdhdmluIEZsb3dlcjwvbWV0YTppbml0
aWFsLWNyZWF0b3I+PG1ldGE6Y3JlYXRpb24tZGF0ZT4yMDA4LTA1LTI1VDA5
OjM3OjA4PC9tZXRhOmNyZWF0aW9uLWRhdGU+PGRjOmRhdGU+MjAxMS0wNC0x
NVQwODo0NTo1MjwvZGM6ZGF0ZT48ZGM6Y3JlYXRvcj5HYXZpbiBGbG93ZXI8
L2RjOmNyZWF0b3I+PG1ldGE6ZWRpdGluZy1kdXJhdGlvbj5QVDFIMzRNMzhT
PC9tZXRhOmVkaXRpbmctZHVyYXRpb24+PG1ldGE6ZWRpdGluZy1jeWNsZXM+
MTg8L21ldGE6ZWRpdGluZy1jeWNsZXM+PG1ldGE6Z2VuZXJhdG9yPkxpYnJl
T2ZmaWNlLzMuMyRMaW51eCBMaWJyZU9mZmljZV9wcm9qZWN0LzMzMG0xOSRC
dWlsZC0yMDI8L21ldGE6Z2VuZXJhdG9yPjxtZXRhOmRvY3VtZW50LXN0YXRp
c3RpYyBtZXRhOnRhYmxlLWNvdW50PSIxIiBtZXRhOmltYWdlLWNvdW50PSIw
IiBtZXRhOm9iamVjdC1jb3VudD0iMCIgbWV0YTpwYWdlLWNvdW50PSIxNSIg
bWV0YTpwYXJhZ3JhcGgtY291bnQ9Ijg3MSIgbWV0YTp3b3JkLWNvdW50PSI0
MTU4IiBtZXRhOmNoYXJhY3Rlci1jb3VudD0iMzE2NTUiLz48bWV0YTp1c2Vy
LWRlZmluZWQgbWV0YTpuYW1lPSJJbmZvIDEiLz48bWV0YTp1c2VyLWRlZmlu
ZWQgbWV0YTpuYW1lPSJJbmZvIDIiLz48bWV0YTp1c2VyLWRlZmluZWQgbWV0
YTpuYW1lPSJJbmZvIDMiLz48bWV0YTp1c2VyLWRlZmluZWQgbWV0YTpuYW1l
PSJJbmZvIDQiLz48L29mZmljZTptZXRhPjwvb2ZmaWNlOmRvY3VtZW50LW1l
dGE+UEsDBBQAAAgAALqljj4GlMTZ8gwAAPIMAAAYAAAAVGh1bWJuYWlscy90
aHVtYm5haWwucG5niVBORw0KGgoAAAANSUhEUgAAALUAAAEACAIAAAB6QaCM
AAAMuUlEQVR4nO2dba+EKAyFucn+/788u8lkDVPgUOhBUc/z4cbr1Fq08tKC
/vP5fJIQDf652gCxNfIPgZB/CIT8QyDkHwIh/xAI+YdAyD8EQv4hEPIPgZB/
CIT8QyDkHwIh/xAI+YdAyD8EQv4hEJP+8ff3Nz3xrHpsRKH/LCus+k/m2P5P
+Pj3u338jZhxITP+8b0ER+GP/eXVMdtHyfNjj43qsVXlpc7SmNZOY1h+XmNP
vhOUwnHBkjE1V5g7UH5hPWpPYMY/qvcv/6klkJfcXOv8WL8BrUOqbpF+n/Xc
jPwo4E+mIN3CYgPM9j4+kTPZvhyFad0bs9/4QVdb9WJVlXw38r9AFRDznLe1
4SydX/8+LOmfblhOMYfGLwIh/xAI+YdAzI9vxR0Z7RpGxy9BwLiu9dNoIIul
5zSTzK+soqWpB5vfvlTjZnOHt0IRzrBmVc9EJGq1SUbPtD0rgmwL+x8gjIaP
MhpaoS2/nvR77VaY5AzrdfVM21MNx8XZtH/qiUQN6WmpvdAkrp5FQTa+f7QC
mpj8YTLPhNmfajmUXE++v6rNnOs4CrflRlVpQ7fVB3qc1cBo6cyeCbaoP3CT
2aqHW+3X5/80CrhbJhNUVVW6UfmrOap1UmxSVTi1g/H+0sXrkpB/mP527t1m
u+rgB+ZCm3a9VIu7cubO5ZesWweUVlVVtWxu3Q+PSWW5PH7ZKl15Jee4pv6o
uojZOLaHGizcqI8qxJKlqUGTugyponRE5v2jVS17hLl9KLGOef8oXbi7XfX6
eB24px6iKqJJozDbl2o/AzfM+Kdc7b1ktjWpK2Mg9z9wn9FzOOjipdq4rnpS
j55SSaszCKzNTTLmnW/SkD1OyP5R7ZCnqUDIkPyQiwyddM6euKoT9Hjg+Efu
rZGRt6fDWx2djurxKHHak2uLqCKa5LHHCcc/iOORlqpqJ3eiW9MaP4/qaZk0
oYpl0qg9HraIn4ptmV8fxbLAWYHfTmZPk0aZnx8U7Ph82W0QqPGtQe2LQNzJ
P7jhSBNvmBjHmj2eYGBXm4lejBa5Nfy5IP5xVQ6let5p14m0kiaWNZSQKm0w
buoZ63rMmzv2INQ/rUb3yv04IGjEWiG1/Fh/AKCqKv0+60AbrlpMABeowhVV
uTN3kVKVEWudhVLdRtuXlrnm2pXyo09teflaZoAD8z0mWjBK1Z5IVVTV0PI5
0IgQgx8p2L5Ua4vcPtBIn8NVjeBqTruGofUvZf1WFUu/7Q4O/+EGqKU/ogq0
IJ5nMa8RPXpa2spGCqjC9piHMPKQMMcvE9Fu+ok8zA1YuvYEFZoGi1VDBMvI
z8+txnQJ55T8/c4knTYmf1iDPmfqoWmT0m/tGPTa0PzC1G5iVvgK7qLO6Qlq
o3R1y2O5pYtAa1+6Dae4I9H4mKfjKe4LJ38baS93S3Iqf5uz7/sdbi2zrUld
GUN0/cv04eIWXPD+ZHEjLp4fdOCPjXaDFixVRk/3jE490/YQTfKzV36/ldO5
UBUrlEks2qGQogdDbl9aoeuhDhSl5CxVrHHBHZ0jBduXcuexXV4OXDf6C9yV
ZKnaTQ9XlZMz3k9Xor7tXYjO/wB1Rt7iyiFuSjR+CibAAZmq/MNk9jRpFMVP
l8hsa1JXxqD4qUDcaf2LOJ/r19+Knbm4/yE2h5+fA6HV78Z0vsM5w5ulqjsF
vDwLmHMJztU6qntSIMAK50fjp59swdYxi6xl4rEx3bcl1lvESaPO8WcrqXko
MRczfpWuzM99Ge2IHGWeKLy5jkPHVlUdJqXZS1nOFG8ZBu53NVMxXUBTtGvq
j1Rc0Fa01NQi+V+sEJ/3hJTHXDakVT0AheZy+YUnzBtl7fooz70UO8MZ38oD
noriYwKh+IdAqP4QiOvj67slwZXfz1F+f4nMtiZ1ZQxa/yIQ6n8IhMYvAkF7
v2V3DVk37eKMuY0mb7tWOU0Cj0Q3g+MPJ+KGm3WJ/BC+b5p+7S7T2TmsvLMn
OULJ5O1Jt1ysghPyc1U7chf2P9Cjpwb8ZW8YwwJ3bCvPcY5E6X+UidyqcDW7
iw+cE2PpOd+kruTJydtE/37ldyOSvhdbEY2fmv7d9NwfsSeE92unX4d4ZH/w
tRDer22GMKo5ngTz/acsVWIflL9dJbOnSaOE6o94nbFbklP5W8Ne7x8Tu3Gb
/JxJheD4rEdPqWS0UNXDI3oMLD0Tqg7ulN8vcz3TxS5X6JzTVgJ7yhhBZAlZ
rnbOpC+c+UGmbDivWP3Vk6PJwy2p5i5DqozBpdk4WZon/47tatn9Revey27+
1gjEO62E9xcCK0GV23Kj1l3HWZtWrrj8qZU5Ak8qSDE6NWBTg5XEtB4PtPGL
ibKXjlwNplUVtn4tqw18Uz2qumE93Pr4GztsT6kNK+zmpZ1WdeGMX8p71vq1
PLalrXXSbqvsUeVpmE1SCcjg7sJQHZNgGT0mGT1dMcxJ3yfs/uqEFQUy/YbL
7UntpyuiMK7nfuOXcvtCVcQmn6WK2wvR+gaBuFP9Ic7nNvFTcQnK366S2dOk
UZS/XSKzrUldGQPz+y/ieVzfvoidUf9UIDS+FQja+uyuQCuNnsvntFK++Uyc
lhhW1ZoeMJTfHzLbI/MpFgx3VXn0XJyfM9e3lcU1wqC/PTo0mFbl7PN3M4Ll
fQWS3dN5LPTr8aQzMZz2pfVsmauW/9utSJw6AUDVhBJszFCIIlg04iXqEu2f
GhPLas3UHK38pPNRxkqcqvLDu7l7p56umFMmmAMv9VzWvrQIVoliKwjrs3nG
iO0gfN9DLvJgFB8TCMXHBOL6/MtuSXDl93OWrH/xs1sSXPl9g9oXgZB/CITe
7yAQ5PUNOGfYTRzk/2Il3dwbRRVe8zenJ2IP0SQnzPmFrWx+dWWYAmu3YFX+
pczbHdtmAofYmej7T82NL2WOv9UUrrO2LHXGZTxiu+nhqvLAXN8QzE2LDdH3
kQVC8Q+BUP5WIFR/CITyt6tk9jRplFB8LD59frckp/K3BrUvAsH5fqV4Ksrf
CsTa9bdpJCHnWVyafFPXKKqcSgzTqWln6boZCaPnsvVR1QSKWX9rBOLtEbHS
8i9Z6y7xZS1pzE2KaGMtnktL19+m31qE5RyUm1GmFXERqsbnDwDROYLaqqny
adauv81/zRua8sDqHnBqVi4QSJ6fdPUIU4rmh7++kpXsFjvA7H/k+8UziMY/
WHaIPSF8H1k8GMXXBUL521Uye5o0Cmf97fQ4e7ckp/K3hmj7Qgl8iW3hvD9I
LvJUmN8nFM9D4xeBWJXfb0mClmi39dn+NT7dRvZ167ONHVWcEyb2582t56r5
Y09yjm41Q5n8sSfk/L6h9WaH6oHn59OdLu4RoyTlTyuaH2Z+v2yAq1a+ubq+
HYTxy1OrVpGI49tvG6xA2cMgrM8mzoYVu6H87SqZPU0a5eL3O+yW5FT+1jDf
/zD5/cSeWS92gJDfP7ZNpIi7kEtcAjO+3loLM6Gq1GbETsi/JFi6aT0Re4gm
OeHH18uhjWqO+8J5v/bxr7odD4PQP23tH+15bJik2E0PV5WH6PuT/fvFHaGt
j6qmatXW3B1m/oWlSuyD4uurZPY0aRTa91+0PuoWJnVlDFofJRD6vrpA6P2W
ArF2/Uu+MATXNCat0F1LovxL0CQnhPcnmzztl2qUrFs2T2xN9daZLGlfqotf
Pr+vhKge+Od4V6RmC5wJZ/5YNU9bzlgecqmI5G55kzfmXw4od13sCSd/q0li
T2Vt/SHuDq1/Ki95JHo/jEAof7tKZk+TRlH+donMtiZ1ZQzK3woEZ/2LXOSp
KH8rEPzvA5WSh4w/hdvSXC6eqEr6+0ZDWeWW2JAeoIqYv+2a5IT/faAE07Bq
ie7Fku8DnbD+RUtsMKzrc8b3gY5qE8tfkr2Mm0TU88z8bRc1KPeFED8tZ45F
jRLbwHw/jHgezPlj4nkofysQyt+uktnTpFGUv10is61JXRkDp3+qaNVTWfh9
IPEAlL8ViND7C49mr0zSmhbRrMSsKjR7ppOupTatv52GsP6lnCKUL5M0O8v9
OZ9sMfe0YYII//2F+U9mZWX3rnvW34ozIeRvzUNvUrvVnS2FQ2ePCNxUD1eV
B078FNx+dWNvjeLrAsF5/7p4KqH+h7zk8YTaFznH41H+dpXMniaNMuMfqjbe
g8YvAiH/EAj5h0DIPwRC/iEQ8g+BkH8IhPxDIOQfAiH/EAj5h0DIPwRC/iEQ
L/UPvBLHzH568zSol/pHqi25MAu6cuHXush7/SONvMX1tbzUP8pFOmYpV+4x
b/ael/qH4c0egJF/CIT8QyDkHwIh/xAI+YdAyD8EQv4hEPIPgZB/CIT8QyDk
HwIh/xAI+YdAyD8EQv4hEPIPgfgXLabEUa2x4V8AAAAASUVORK5CYIJQSwME
FAAICAgAuqWOPgAAAAAAAAAAAAAAAAwAAABzZXR0aW5ncy54bWy1Wl1z2joQ
fb+/IuP3lATyQZiEDpDS0pDCAGnm9k3YC+hG1nokOcC/70qG3BRMSw16ysSW
drWrPbtn19x+XMTi5BWU5ijvgvMPZ8EJyBAjLqd3wdOofVoNPtb/ucXJhIdQ
izBMY5DmVIMxtESf0Hapa9nruyBVsoZMc12TLAZdM2ENE5DrbbX3q2tOWfZk
Ibh8uQtmxiS1Umk+n3+YVz6gmpbOb25uSu7temmIcsKn+6rKVr9XhYhviuyG
7DBOWfns7KKU/R+crA75zjXloL72w9r8+u1KQfbnlBuIrW9OVo/t0e4CUll7
5TB/81qQt+/XPd9pfUMBG2ESrN+YZUJvuDRB/aJavb66LW1L2V9yFyYmT3S5
Urk8TPIzj8wsT/R5tXJRPUz2F+DTWe65Ly5vKsVkD2c4H0BEUQatGZNT0Bvy
x4gCmAzqRqVQTEdHNhXONTxiBLukT5jQe4s/jVlyymUEC4i2XZUfYm4PgUMt
93N4J9o4qjaK4jeo22guF7/IXaF3flOunBUXuwMrl+fVcsHI+M41HwvwARUn
2Ae6neDBLpSUz66qhW/OiW6iMRjnOrpycXVdTPYPxHhEkjbjbYbKxsUBocaW
mJoWijSWm7A+lvQm4svRcL3tlzYLDar8s5evC15mRw9BQGggait6UODoOQ/f
55ddr1cpK38BFcj9S2r2IFXMUIH+m9raiKI+U2yYsJB2jHDEKKxbIISHvN+n
hGn6LAHVVhgPwaSbiD9GmHT0AyjZ0JzJfipDkzqfeFDkzBmAZUWwWRyOIb9L
TO8piZjJK5SH4fUev6FpscSkCu4Vm/fG/+me7LOpD9wO2St8z6hjT7YEah9K
3GV8ihOztFb4Ct4hYUTAVxzvVHCACQ0hcO7UkIIWkyGI45tBeHdJrjeZUJbw
YYazwLIEnxfh0pQX4WioErRRbVb1Y7iGGLUyjdRgBmtPvmkhVR30lsBB5WZu
puHqosklU8ugtIcrUqWoOt4zw+xW+3eIqQq38lzGsveQ2EUWDYBFKMXSx939
euAWxjGTO3qCfexHqXkEagQL86xY0pOUg/voJa8kiVg+aVD27F4yimUQDpEr
GnF8JW0OIvKJnM5UooI2V9pQ3YUOMTNpOvJbGo9B/cakA+6FPKYHIIievFLz
k2n0ZZjV1ZBRUzD5oim7WRtbTISp8MqOGlKicRp2U5iCTW5O2DXM0FCCPb4P
CTw9Ea2y3yMQyEMfQHW2DHD+AOCDGK/O/227xdk/bTkZbbY4SMiTXFAIhvAD
FH5aEFdgkR+EZVSBMmxfsBBmKCjhelDj2PTXVBs+WVpg6WduZo9Mpkw0FbAX
b72HHWx4YlmWqlCvDYoKXaJAW/a+eyhREMOEK8u0/q+CiZ846OguG4O4X83D
vXB3PpWE36HBhKo4/11SPZB/feERVQrrMV+hPABqDWxybRijbLWgKthGL35b
jQSm0GThy1RhukWpjhHLudQtJ5rd5K5gLHfkKyjTREU55g806AB/9VJjR/Nd
eAXxr+VE2idDyW5HoU6oJ/Il/zPhfvabglr83u3g4bPAMXtDvh2peOt5144a
jLoeVLzlSlth/AUY0SoqyaAkE3+oywfRqcwUannIX+t86ceg1cesVWNPah5g
qz38295V8KSh3ypkQ4ZUBSF6VrRUtcXSDVh8hFnGQ30ivoVCsESDm6TZMbAt
A54KmR08uim1rzmFbansZ3ALfPdxYscXvBnxqFPiOChSGyCFyXvDjb2yRo4C
3LpuapOb7sgu194SKDV14Yutz15CzvXbdl4/gjgRhXrvnV83Sls/ISjt+nFF
/SdQSwcIhZdSqk8FAACeIQAAUEsDBBQACAgIALqljj4AAAAAAAAAAAAAAAAV
AAAATUVUQS1JTkYvbWFuaWZlc3QueG1stZZNbsMgEIX3OYXFtrJps6qsOJFa
qSdIDzDBYweJP8EQxbcvjpTEbdOqScMO0PC9NwOMWKz2WhU79EFa07Cn6pEV
aIRtpekb9r5+K5/ZajlbaDCyw0D1cVCkfSacpg2L3tQWggy1AY2hJlFbh6a1
Imo0VH+Or0el5aw4gzupsEyBfijOYthKKGlw2DBwTkkBlHzynWmrg1Y1lagI
98TOuydZzSfLXVSqdEDbhnHGr/JwmfJqTSf76A/ewpwHAophAz4PHoRAhWlq
PRfR+zHzVNzsWlkEOmWBMBPcWRdduhkxE97b3mPId9JkrXJgUOXBj5XJ6j0b
XGroMfAXSRpcyKpxJftrlwrRjI+zirISU4G/efiH+EYa8MNlGQWDjVQKEFu8
UmJssXzsNhfBKUW6rR1Nrfu2e/hR4rhWpai7eg80KAw3WP8dq5HgBujh9nFn
+svU9TbqjQGpAqfjsBqj7/ESJvD7VhiJ0rfiVOMF//arWH4AUEsHCOnUItV0
AQAAkAgAAFBLAQIUABQAAAgAALqljj5exjIMJwAAACcAAAAIAAAAAAAAAAAA
AAAAAAAAAABtaW1ldHlwZVBLAQIUABQAAAgAALqljj4AAAAAAAAAAAAAAAAa
AAAAAAAAAAAAAAAAAE0AAABDb25maWd1cmF0aW9uczIvc3RhdHVzYmFyL1BL
AQIUABQAAAgIALqljj4AAAAAAgAAAAAAAAAnAAAAAAAAAAAAAAAAAIUAAABD
b25maWd1cmF0aW9uczIvYWNjZWxlcmF0b3IvY3VycmVudC54bWxQSwECFAAU
AAAIAAC6pY4+AAAAAAAAAAAAAAAAGAAAAAAAAAAAAAAAAADMAAAAQ29uZmln
dXJhdGlvbnMyL2Zsb2F0ZXIvUEsBAhQAFAAACAAAuqWOPgAAAAAAAAAAAAAA
ABoAAAAAAAAAAAAAAAAAAgEAAENvbmZpZ3VyYXRpb25zMi9wb3B1cG1lbnUv
UEsBAhQAFAAACAAAuqWOPgAAAAAAAAAAAAAAABwAAAAAAAAAAAAAAAAAOgEA
AENvbmZpZ3VyYXRpb25zMi9wcm9ncmVzc2Jhci9QSwECFAAUAAAIAAC6pY4+
AAAAAAAAAAAAAAAAGgAAAAAAAAAAAAAAAAB0AQAAQ29uZmlndXJhdGlvbnMy
L3Rvb2xwYW5lbC9QSwECFAAUAAAIAAC6pY4+AAAAAAAAAAAAAAAAGAAAAAAA
AAAAAAAAAACsAQAAQ29uZmlndXJhdGlvbnMyL21lbnViYXIvUEsBAhQAFAAA
CAAAuqWOPgAAAAAAAAAAAAAAABgAAAAAAAAAAAAAAAAA4gEAAENvbmZpZ3Vy
YXRpb25zMi90b29sYmFyL1BLAQIUABQAAAgAALqljj4AAAAAAAAAAAAAAAAf
AAAAAAAAAAAAAAAAABgCAABDb25maWd1cmF0aW9uczIvaW1hZ2VzL0JpdG1h
cHMvUEsBAhQAFAAICAgAuqWOPjWrTW5BAAAAiwAAAAwAAAAAAAAAAAAAAAAA
VQIAAGxheW91dC1jYWNoZVBLAQIUABQACAgIALqljj5i3rRj4BwAAJf6AQAL
AAAAAAAAAAAAAAAAANACAABjb250ZW50LnhtbFBLAQIUABQAAAgIALqljj7f
PTwx8wAAABQCAAAMAAAAAAAAAAAAAAAAAOkfAABtYW5pZmVzdC5yZGZQSwEC
FAAUAAgICAC6pY4+fr7EB48JAAA2NwAACgAAAAAAAAAAAAAAAAAGIQAAc3R5
bGVzLnhtbFBLAQIUABQAAAgAALqljj7ES+Wp4AQAAOAEAAAIAAAAAAAAAAAA
AAAAAM0qAABtZXRhLnhtbFBLAQIUABQAAAgAALqljj4GlMTZ8gwAAPIMAAAY
AAAAAAAAAAAAAAAAANMvAABUaHVtYm5haWxzL3RodW1ibmFpbC5wbmdQSwEC
FAAUAAgICAC6pY4+hZdSqk8FAACeIQAADAAAAAAAAAAAAAAAAAD7PAAAc2V0
dGluZ3MueG1sUEsBAhQAFAAICAgAuqWOPunUItV0AQAAkAgAABUAAAAAAAAA
AAAAAAAAhEIAAE1FVEEtSU5GL21hbmlmZXN0LnhtbFBLBQYAAAAAEgASAKoE
AAA7RAAAAAA=

--0-856331383-1302815684=:79604--
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: RAID6 data-check took almost 2 hours, clicking sounds, system unresponsive

On 14 April 2011 22:14, Gavin Flower wrote:
> --- On Fri, 15/4/11, Phil Turmel wrote:
>
>> From: Phil Turmel
>> Subject: Re: RAID6 data-check took almost 2 hours, clicking sounds, =
system unresponsive
>> To: "Gavin Flower"
>> Cc: "Mathias Burén" , neilb@suse.de, l=
inux-raid@vger.kernel.org
>> Date: Friday, 15 April, 2011, 1:16
>> Hi Gavin,
>>
>> I think you might want to investigate your *power supply*
> [...]
>
> Attaching OpenDocument file with full details of smart output and com=
parison table.
>
>
> Cheers,
> Gavin

sda has a value higher than 0 on reported uncorrected sectors. That's
enough for me to replace a drive. (heck, even if I see 1 reallocated
sector I'd RMA it ASAP).

Regards,
Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" i=
n
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: RAID6 data-check took almost 2 hours, clicking sounds, systemunresponsive

On 04/14/2011 05:12 PM, Gavin Flower wrote:

>
> Hi Phil,
>
> I was under the impression that I had an adequate power supply, so I checked all 5 drives. In fact I made a table to compare all the smart entries. The differences I thought were significant follow later. I have the full comparison table, and the original smart output, in an OpenDocument file - which I will attach to a separate email (in case it gets blocked/dropped or some such).
>
> Note that Power_Cycle_Count is anomalous only for /dev/sdc, so would this suggest cable problems?

No two drives are perfectly identical, so when the drive's power rail is only slightly overloaded, the least tolerant drive chokes as the voltage declines (we're talking tens of milliseconds, here). As soon as it chokes, the extra load disappears, and the power supply recovers. The other drives carry on. The drive that choked resets (*Click*) in time for the block driver to try again, and the cycle repeats.

As a test, borrow another power supply and hook just that one drive to it. If the problem continues, the drive is toast. If the problem goes away, look for a better power supply. Note: for the Barracuda with the problem, the detailed spec says the 5V load spikes on activity, not the 12V load. So make sure the current capacity of the power supply meets your needs for both 5V & 12V (plus your motherboard). Also check if the power supply has multiple regulators for drive power, and if you need to re-arrange the connectors to spread the load evenly amongst them.

As another test, you can swap all your cables around. If the problem is in the cables, the problem will follow the cables to the drive you moved them to.

> I am not sure what to make of the other discrepancies.
>
> Note that sda, sdb, sdd, & sde were bought and put in at the same time, while sdc was only obtained and inserted recently.

So sdc came from a different manufacturing batch, which is likely to have slightly different tolerances.

HTH,

Phil
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: RAID6 data-check took almost 2 hours, clicking sounds, systemunresponsive

On 14/04/2011 22:19, Mathias Burén wrote:
> On 14 April 2011 22:14, Gavin Flower wrote:
[...]
>> Attaching OpenDocument file with full details of smart output and co=
mparison table.
[...]
> sda has a value higher than 0 on reported uncorrected sectors. That's
> enough for me to replace a drive. (heck, even if I see 1 reallocated
> sector I'd RMA it ASAP).

I've had a look at some of my drives' SMART output, and only my Samsung=
=20
drives have it - one showing 57 (with zero reallocated, pending or=20
offline sectors) and one showing 331 (zero reallocated, one pending and=
=20
zero offline sectors). Neither drive has ever given a read error, and I=
=20
do run a weekly check on my arrays which has never reported any mismatc=
hes.

Googling for this field doesn't give any indication that it is relevant=
=20
to determining whether a drive is failing, but if someone with more=20
SMART expertise can comment I'll be quite happy to be corrected...

Having said that, all of Gavin's drives apart from sdc show non-zero=20
reallocated sector counts, and that field definitely is one to follow=20
when considering replacing drives.

Cheers,

John.
(Just started long self-tests on all my local drives)

--
To unsubscribe from this list: send the line "unsubscribe linux-raid" i=
n
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: RAID6 data-check took almost 2 hours, clicking sounds, system unresponsive

--- On Fri, 15/4/11, Phil Turmel wrote:

> From: Phil Turmel
> Subject: Re: RAID6 data-check took almost 2 hours, clicking sounds, s=
ystem unresponsive
> To: "Gavin Flower"
> Cc: "Mathias Bur=E9n" , neilb@suse.de, linux=
-raid@vger.kernel.org
> Date: Friday, 15 April, 2011, 10:23
> On 04/14/2011 05:12 PM, Gavin Flower
> wrote:
>=20
> >=20
> > Hi Phil,
> >=20
> > I was under the impression that I had an adequate
> power supply, so I checked all 5 drives. 
[...]
> >=20
> > Note that Power_Cycle_Count is anomalous only for
> /dev/sdc, so would this suggest cable problems?
>=20
> No two drives are perfectly identical, so when the drive's
> power rail is only slightly overloaded, the least tolerant
> drive chokes as the voltage declines (we're talking tens of
> milliseconds, here).=A0 As soon as it chokes, the extra
> load disappears, and the power supply recovers.=A0 The
> other drives carry on.=A0 The drive that choked resets
> (*Click*) in time for the block driver to try again, and the
> cycle repeats.
>=20
> As a test, borrow another power supply and hook just that
> one drive to it.=A0 If the problem continues, the drive
> is toast.=A0 If the problem goes away, look for a better
> power supply.=A0 Note:=A0 for the Barracuda with the
> problem, the detailed spec says the 5V load spikes on
> activity, not the 12V load.=A0 So make sure the current
> capacity of the power supply meets your needs for both 5V
> & 12V (plus your motherboard).=A0 Also check if the
> power supply has multiple regulators for drive power, and if
> you need to re-arrange the connectors to spread the load
> evenly amongst them.
>=20
> As another test, you can swap all your cables around.=A0
> If the problem is in the cables, the problem will follow the
> cables to the drive you moved them to.
>=20
> > I am not sure what to make of the other
> discrepancies.
> >=20
> > Note that sda, sdb, sdd, & sde were bought and put
> in at the same time, while sdc was only obtained and
> inserted recently.
>=20
> So sdc came from a different manufacturing batch, which is
> likely to have slightly different tolerances.
>=20
> HTH,
>=20
> Phil

Thanks Phil,

A few days ago, I noticed that 2 of my 3 RAID arrays were down to 4 out=
of 5 drives - /dev/sdc had been dropped out, the one which made clicki=
ng sounds when I ran badblocks.

A couple of days ago, my friend Mario brought over his oscilloscope and=
a volt meter. The 5 volt rail was showing about 4.7 volts, typically =
it should be 5.2 - 5.4 (from memory of what he said), and the voltage l=
ooked shaky on the oscilloscope. The old power supply rated at 400 Wat=
ts. =20

Mario suggested that power supplies greater than 500 Watts had signific=
antly better quality, also he and others said that power supplies tende=
d to have reduced capability to supply their maximum power as they age.=
So while, 400 Watts seemed nominally adequate for my system, I starte=
d looking for ones that wee at least 500 Watts, I also looked at other =
features, such as reliability and the ability to support at least 5 sat=
a drives without using adapters.

I was in the process of checking out various power supplies, when my de=
velopment machine ('saturn') refused to complete the boot process due t=
o RAID problems.

There are many power supplies that would have met my requirements, but =
I told Mario that I was prepared to pay a bit extra, if there was real =
benefit, as I saw no point in being penny wise and pound foolish as the=
y say in England. If the time Mario and I (let alone that of the other=
s who advised me) had spent on this problem was costed, it would have b=
een more than double the price of the power supply, so I figured paying=
a bit extra was a good investment. The one Mario obtained for me was t=
he one in stock that met my needs without being too expensive. The new=
one is 700 Watts with reasonably robust specifications: Cooler Master =
Extreme Power Plus 700W. MTBF > 100,000 hours (11 years), high efficie=
ncy 80% at typical load...

Reassembling the 2 defective RAID-6 partitions went okay, now all 3 RAI=
D partitions are complete.

Been running over 16 hours now and no apparent problems. I ran badbloc=
ks on all 5 disks concurrently - no clicking sounds were heard, nor wer=
e any errors reported. Also the 'ata' errors previously seen on the sys=
tems log are absent.

I very much appreciate the help provided to me by the people on this li=
st.


Regards,
Gavin
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" i=
n
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: RAID6 data-check took almost 2 hours, clicking sounds, systemunresponsive

--Sig_/ySTMAom.7xIPIOb.rPcvVWa
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

On Thu, 28 Apr 2011 13:03:39 -0700 (PDT)
Gavin Flower wrote:

> A couple of days ago, my friend Mario brought over his oscilloscope and a
> volt meter. The 5 volt rail was showing about 4.7 volts, typically it
> should be 5.2 - 5.4 (from memory of what he said), and the voltage looked
> shaky on the oscilloscope. The old power supply rated at 400 Watts. =20

4.7V is fine, those voltages have a tolerance of +/-10%. And if you have a
deviation there, it is actually better for it to be to the lower side, than
equivalent to the higher. Reason: no heat increase.

--=20
With respect,
Roman

--Sig_/ySTMAom.7xIPIOb.rPcvVWa
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk25yeYACgkQTLKSvz+PZwhRawCglOU05ihi4rS6H7tbiZ0k nh5U
NPoAn36+EJxkaluNHDW8SrF6GkaXMaaA
=oHKY
-----END PGP SIGNATURE-----

--Sig_/ySTMAom.7xIPIOb.rPcvVWa--
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: RAID6 data-check took almost 2 hours, clicking sounds, systemunresponsive

On 04/28/2011 04:11 PM, Roman Mamedov wrote:
> On Thu, 28 Apr 2011 13:03:39 -0700 (PDT)
> Gavin Flower wrote:
>
>> A couple of days ago, my friend Mario brought over his oscilloscope and a
>> volt meter. The 5 volt rail was showing about 4.7 volts, typically it
>> should be 5.2 - 5.4 (from memory of what he said), and the voltage looked
>> shaky on the oscilloscope. The old power supply rated at 400 Watts.
>
> 4.7V is fine, those voltages have a tolerance of +/-10%. And if you have a
> deviation there, it is actually better for it to be to the lower side, than
> equivalent to the higher. Reason: no heat increase.

Uh. Close, but no.

Quoting the Seagate manual for that drive:

> 2.7.3 Voltage tolerance
>
> Voltage tolerance (including noise):
> 5V +10% / -7.5%
> 12V +10% / -10.0%

So he was somewhere around 75mV above the low spec, and it was "shaky". If his meter was rounding up to 4.7 from 4.65, he could have been as close as 25mV to the low spec.

Based on the manual, the best noise tolerance will be at 5.0625V, the middle of the spec.

There might be big datacenter engineers that'll trade some noise margin for heat dissipation savings. For that drive's active power consumption, a 5% voltage reduction (half of his noise margin) will save him, at most, 28W (5 drives * 6.19W * 0.95^2). That's a savings of $14 per year for 24/7/365 usage in my household.

I'd spend the $14 for the safety margin on *my* data. (And I do.)

Regards,

Phil
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: RAID6 data-check took almost 2 hours, clicking sounds, systemunresponsive

Whoops! Hasty. See below.

On 04/28/2011 06:11 PM, Phil Turmel wrote:
> On 04/28/2011 04:11 PM, Roman Mamedov wrote:
>> On Thu, 28 Apr 2011 13:03:39 -0700 (PDT)
>> Gavin Flower wrote:
>>
>>> A couple of days ago, my friend Mario brought over his oscilloscope and a
>>> volt meter. The 5 volt rail was showing about 4.7 volts, typically it
>>> should be 5.2 - 5.4 (from memory of what he said), and the voltage looked
>>> shaky on the oscilloscope. The old power supply rated at 400 Watts.
>>
>> 4.7V is fine, those voltages have a tolerance of +/-10%. And if you have a
>> deviation there, it is actually better for it to be to the lower side, than
>> equivalent to the higher. Reason: no heat increase.
>
> Uh. Close, but no.
>
> Quoting the Seagate manual for that drive:
>
>> 2.7.3 Voltage tolerance
>>
>> Voltage tolerance (including noise):
>> 5V +10% / -7.5%
>> 12V +10% / -10.0%
>
> So he was somewhere around 75mV above the low spec, and it was "shaky". If his meter was rounding up to 4.7 from 4.65, he could have been as close as 25mV to the low spec.
>
> Based on the manual, the best noise tolerance will be at 5.0625V, the middle of the spec.
>
> There might be big datacenter engineers that'll trade some noise margin for heat dissipation savings. For that drive's active power consumption, a 5% voltage reduction (half of his noise margin) will save him, at most, 28W (5 drives * 6.19W * 0.95^2). That's a savings of $14 per year for 24/7/365 usage in my household.

Sorry. 28W is what they'll *consume* @ -5%. The *savings* is 3W (5 drives * 6.19W * (1-0.95^2)), at most. $1.50/year.

> I'd spend the $14 for the safety margin on *my* data. (And I do.)

I'd still spend $14, if that's what it was.

Phil
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html