Probleme mit Raid 5 im Server

[perdlox]

Guten Abend,

ich habe ein größeres Problem...nachdem mein alter Raid Controller seinen Geist aufgegeben hat, ich aber zum Glück noch ein aktuelles Backup machen konnte, hab ich mir n neuen Raid Controler gekauft.

Dies ist der HighPoint RocketRadi 2340 mit 8x1TB von WD. Das Raid ist ein Raid 5 und mit cryptsetup und Luks verschlüsselt. Die HDDs sind im Schnitt um die 50°C warm (wenn sie ackern, ansonsten normal 35°C)...

Nun kam einmal beim formatieren und einmal beim kopieren folgender Fehler:

Aug 27 21:08:08 server kernel: [39963.881653] BUG: unable to handle kernel paging request at ffff8a00277a1668
Aug 27 21:08:08 server kernel: [39963.881670] IP: [<ffffffff8035c0b2>] __ext3_journal_stop+0x42/0x60
Aug 27 21:08:08 server kernel: [39963.881683] PGD 0
Aug 27 21:08:08 server kernel: [39963.881690] Oops: 0000 [#1] SMP
Aug 27 21:08:08 server kernel: [39963.881697] last sysfs file: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
Aug 27 21:08:08 server kernel: [39963.881709] Dumping ftrace buffer:
Aug 27 21:08:08 server kernel: [39963.881716]    (ftrace buffer empty)
Aug 27 21:08:08 server kernel: [39963.881722] CPU 0
Aug 27 21:08:08 server kernel: [39963.881728] Modules linked in: aes_x86_64 aes_generic xts gf128mul msr video output input_polldev dm_crypt lp parport snd_hda_$
Aug 27 21:08:08 server kernel: [39963.881790] Pid: 7588, comm: cp Tainted: P           2.6.28-14-server #47-Ubuntu
Aug 27 21:08:08 server kernel: [39963.881800] RIP: 0010:[<ffffffff8035c0b2>]  [<ffffffff8035c0b2>] __ext3_journal_stop+0x42/0x60
Aug 27 21:08:08 server kernel: [39963.881813] RSP: 0018:ffff8800277a1658  EFLAGS: 00010246
Aug 27 21:08:08 server kernel: [39963.881820] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000001
Aug 27 21:08:08 server kernel: [39963.881827] RDX: 0000000000000000 RSI: ffff880076ca1b10 RDI: ffff880076ca1b10
Aug 27 21:08:08 server kernel: [39963.881834] RBP: ffff8a00277a1678 R08: 0400000000000000 R09: 0000000000000000
Aug 27 21:08:08 server kernel: [39963.881842] R10: ffff880070cc8000 R11: 0000000000000000 R12: ffff880070cd3400
Aug 27 21:08:08 server kernel: [39963.881849] R13: ffffffff806c3b40 R14: 0000000000000001 R15: 000000006136b68e
Aug 27 21:08:08 server kernel: [39963.881857] FS:  00007f51f2be0780(0000) GS:ffffffff80a9a000(0000) knlGS:0000000000000000
Aug 27 21:08:08 server kernel: [39963.881867] CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
Aug 27 21:08:08 server kernel: [39963.881874] CR2: ffff8a00277a1668 CR3: 00000000485f6000 CR4: 00000000000006a0
Aug 27 21:08:08 server kernel: [39963.881881] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
Aug 27 21:08:08 server kernel: [39963.881889] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Aug 27 21:08:08 server kernel: [39963.881896] Process cp (pid: 7588, threadinfo ffff8800277a0000, task ffff880079100000)
Aug 27 21:08:08 server kernel: [39963.881907] Stack:
Aug 27 21:08:08 server kernel: [39963.881912]  ffff880076ca1b10 ffff880076ca1b10 ffff880076ca1b10 ffff8800049ab9c8
Aug 27 21:08:08 server kernel: [39963.881923]  ffff8800277a16a8 ffffffff8035105b ffff8800277a1748 0000000000000007
Aug 27 21:08:08 server kernel: [39963.881938]  ffff8800049ab9c8 ffff880070cd3400 ffff8800277a16d8 ffffffff80307d85
Aug 27 21:08:08 server kernel: [39963.881957] Call Trace:
Aug 27 21:08:08 server kernel: [39963.881963]  [<ffffffff8035105b>] ? ext3_dirty_inode+0x6b/0x90
Aug 27 21:08:08 server kernel: [39963.881973]  [<ffffffff80307d85>] ? __mark_inode_dirty+0x35/0x1d0
Aug 27 21:08:08 server kernel: [39963.881982]  [<ffffffff8034c58c>] ? ext3_new_blocks+0xac/0x720
Aug 27 21:08:08 server kernel: [39963.881991]  [<ffffffff8035e67f>] ? __ext3_journal_dirty_metadata+0x2f/0x70
Aug 27 21:08:08 server kernel: [39963.882000]  [<ffffffff8030d6da>] ? __find_get_block+0xda/0x220
Aug 27 21:08:08 server kernel: [39963.882009]  [<ffffffff8034faaf>] ? ext3_alloc_branch+0x6f/0x380
Aug 27 21:08:08 server kernel: [39963.882017]  [<ffffffff8030f759>] ? __bread+0x9/0x40
Aug 27 21:08:08 server kernel: [39963.882025]  [<ffffffff80351aed>] ? ext3_get_blocks_handle+0x2dd/0x590
Aug 27 21:08:08 server kernel: [39963.882035]  [<ffffffff80351e17>] ? ext3_get_block+0x77/0x130
Aug 27 21:08:08 server kernel: [39963.882044]  [<ffffffff8030ea56>] ? __block_prepare_write+0x1f6/0x5a0
Aug 27 21:08:08 server kernel: [39963.882053]  [<ffffffff80351da0>] ? ext3_get_block+0x0/0x130
Aug 27 21:08:08 server kernel: [39963.882061]  [<ffffffff8030ef79>] ? block_write_begin+0x59/0xf0
Aug 27 21:08:08 server kernel: [39963.882070]  [<ffffffff8035052b>] ? ext3_write_begin+0x12b/0x200
Aug 27 21:08:08 server kernel: [39963.882078]  [<ffffffff80351da0>] ? ext3_get_block+0x0/0x130
Aug 27 21:08:08 server kernel: [39963.882086]  [<ffffffff8035f6cf>] ? ext3_xattr_get+0x5f/0x180
Aug 27 21:08:08 server kernel: [39963.882095]  [<ffffffff802b031c>] ? generic_perform_write+0xbc/0x1c0
Aug 27 21:08:08 server kernel: [39963.882104]  [<ffffffff80361993>] ? ext3_xattr_security_get+0x23/0x30
Aug 27 21:08:08 server kernel: [39963.882113]  [<ffffffff802b14c8>] ? generic_file_buffered_write+0x78/0x140
Aug 27 21:08:08 server kernel: [39963.882122]  [<ffffffff802b2c31>] ? __generic_file_aio_write_nolock+0x261/0x470
Aug 27 21:08:08 server kernel: [39963.882134]  [<ffffffff802b2f47>] ? generic_file_aio_write+0x67/0xd0
Aug 27 21:08:08 server kernel: [39963.882142]  [<ffffffff8034d7d6>] ? ext3_file_write+0x26/0xc0
Aug 27 21:08:08 server kernel: [39963.882150]  [<ffffffff802e77d1>] ? do_sync_write+0xf1/0x140
Aug 27 21:08:08 server kernel: [39963.882160]  [<ffffffff80268920>] ? autoremove_wake_function+0x0/0x40
Aug 27 21:08:08 server kernel: [39963.882171]  [<ffffffff803f6083>] ? apparmor_file_permission+0x23/0x30
Aug 27 21:08:08 server kernel: [39963.882181]  [<ffffffff803d0751>] ? security_file_permission+0x11/0x20
Aug 27 21:08:08 server kernel: [39963.882191]  [<ffffffff802e7e9b>] ? vfs_write+0xcb/0x130
Aug 27 21:08:08 server kernel: [39963.882199]  [<ffffffff802e7ff0>] ? sys_write+0x50/0x90
Aug 27 21:08:08 server kernel: [39963.882207]  [<ffffffff8021253a>] ? system_call_fastpath+0x16/0x1b
Aug 27 21:08:08 server kernel: [39963.882216] Code: 48 8b 06 48 89 f7 8b 5e 10 48 8b 00 4c 8b a0 18 02 00 00 e8 d1 e4 02 00 85 db 74 1d 89 da 4c 89 ee 4c 89 e7 $
Aug 27 21:08:08 server kernel: [39963.882296] RIP  [<ffffffff8035c0b2>] __ext3_journal_stop+0x42/0x60
Aug 27 21:08:08 server kernel: [39963.882305]  RSP <ffff8800277a1658>
Aug 27 21:08:08 server kernel: [39963.882311] CR2: ffff8a00277a1668
Aug 27 21:08:08 server kernel: [39963.882551] ---[ end trace 4ffefbf1daf8671e ]---

Nach diesem Fehler ist jeglicher Zugriff auf das entsprechende Medium ein Todesurteil für die SSH-Console oder Dateifreigabe...

Habt ihr n Rat oder Vorschlag, woran das liegen kann? Ist nicht wirklich schön!

 

[Colttt]

das sieht stark nach nem kaputten dateisystemaus, da hilft nur nochmal neu formatieren..

läuft das raid auch richtig?? was sagen die smart werte der einzelnen platten ist da alles ok??

 

[Elrond der 2te]

Warum ist das Array doppelt verschlüsselt?? Ev. hakt es da, ich würde das ganze mal neu formatieren & ohne Verschlüsselung testen

 

[perdlox]

Das Dateisystem kann nicht kaputt sein...sollte eigentlich nicht und die SMART Werte sind alle im grünen Bereich.

Und woran siehst du, dass es doppelt verschlüsselt ist?

Es ist halt die cryptsetup erstellung

"sudo cryptsetup -c aes-xts-plain -s 512 luksFormat ...."

 

[Elrond der 2te]

Hab ich mich wohl verschaut.. Ich würds aber trotzdem mal ohne Verschlüsselung testen, schon alleine wegen der Zeile:

Modules linked in: aes_x86_64 aes_generic xts gf128mul msr video output input_polldev dm_crypt lp parport snd_hda_$

 

[madd!n]

Der Fehler kommt nicht vom Dateisystem. Er ist zwar bei einem Kopiervorgang (Process cp (pid: 7588,...) entstanden, aber der Grund liegt woanders...

unable to handle kernel paging request

Lass lieber mal memtest einzeln auf deinen Modulen laufen.

 

[perdlox]

Hab es auf beiden laufen lassen...

Was mich verwunder hat, dass memtest die RAMs mit 435Mhz angibt, obwohl die gar nicht übertaktet sind (DDR2-800)...und nach 22h kamen 2 Fehler raus...

Soll ich mir da neue RAMs kaufen oder kann das auch n anderen Grund haben?

 

[madd!n]

Wenn memtest Fehler wirft, würde ich mich persönlich von diesem RAM trennen.

 

[ulukay]

oder feintuning betreiben - wenns ein server is -> ram untertakten, also auf 333mhz laufn lassn, und oder timings entschaerfen und spannung hochsetzen
stabilitaet is bei nem server idr wichtiger als performance

 

[perdlox]

oder feintuning betreiben - wenns ein server is -> ram untertakten, also auf 333mhz laufn lassn, und oder timings entschaerfen und spannung hochsetzen
stabilitaet is bei nem server idr wichtiger als performance

Man lese sich meinen Beitrag durch - es ist nicht übertaktet...alles steht auf auto und an den timings kann ich nichts ändern, die werden automatisch vom board gesetzt...

 

[foxxx]

er hat ja auch nicht gesagt, dass du das oc zurückdrehen sollst, sondern einfach untertakten, damit der ram wieder stabil läuft.

und was ist das bitte für ein board, bei dem man keine timings einstellen kann ?
das konnten alle mir bekannten sockel-a boards, und auch boards anderer sockel, darunter auch oem-boards.
bisher hab ich noch keins ohne manuelle timing-optionen gesehen, aber man lernt nie aus

ich persönlich würde mich aber auch von defektem ram trennen.
solltest du noch garantie haben, einfach mal zum hersteller schicken und gucken was passiert (vorher auf der homepage RMA request etc. ausfüllen )

mfg
foxxx