[Sammelthread] IBM M5014 Raid-Controller [ Flash-Anleitung, Benchmarks, etc. ]

Bei dir steht bei Configured Drives aber ein MAX with cache, bei mir none...

Die Initialisierung läuft noch 5,5std... danach mal testen.
Wo ist eigentlich der unterschied zwischen der 0047 und der 0048?


MfG
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Also ich hab bei mir auch nur die Power Save Funktionen aktiviert (3 Hakerl für alle Arten von Drives, 2 Std. und Power Save auf AUTO belassen).
Funktioniert einwandfrei.

LSI.png
 
Etwas verwirrend. Hab die PowerSave Optionen im BIOS geändert nun passt es.
Über MSM geht es jetzt trotzdem nicht... Egal Hauptsache es funktioniert.


Edit:
Wo ist eigentlich der Unterschied zuwischen der normalen Initialisierung und der schnellen?

MfG
 
Zuletzt bearbeitet:
Die aktuellen Versionen des MSM wird die alten Funktionen nicht mehr handeln können.
Also entweder eine ältere MSM-Version nutzen oder es direkt im BIOS einstellen :)

Die normale Initialisierung wird einfach gründlicher sein.
Ich hab damals immer die längere Variante gewählt, da ich einfach ein besseres Gefühl dadurch hatte.
 
Bei einer schnellen Initialisierung werden nur die Headerinfos geschrieben.
Bei der normalen werden alle Blöcke gelesen und die Checksummen geschrieben.
 
Noch mal zu meinem crashenden Controller. Ich hab hier noch mal ein Log. Kann das sein dass es Bus-Fehler sind?
Hier sieht man wie das anfängt. Filesystem ist BTRFS und es crasht vor allem dann wenn ich per NFS drauf zu greife. Ein Zufall?

Nachtrag:
Auf einer "etwas" älteren Seite haben auch andere das Problem und haben auch NFS an. Ich werde erst mal vermeiden NFS zu nehmen. Mal sehen ob es wieder auftritt
https://bugzilla.redhat.com/show_bug.cgi?id=605444

...
Aug 1 12:58:26 server systemd[1]: systemd-udevd.service: Watchdog timeout (limit 3min)!
Aug 1 12:58:33 server kernel: [410020.373221] INFO: task systemd-udevd:1508 blocked for more than 120 seconds.
Aug 1 12:58:33 server kernel: [410020.373384] Not tainted 4.4.0-31-generic #50-Ubuntu
Aug 1 12:58:33 server kernel: [410020.373493] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Aug 1 12:58:33 server kernel: [410020.373646] systemd-udevd D ffff880128e13938 0 1508 1 0x00000004
Aug 1 12:58:33 server kernel: [410020.373661] ffff880128e13938 0000000000000046 ffff880129c11b80 ffff880128383700
Aug 1 12:58:33 server kernel: [410020.373671] ffff880128e14000 ffff880128e13a90 ffff880128e13a88 ffff880128383700
Aug 1 12:58:33 server kernel: [410020.373680] ffff880128383700 ffff880128e13950 ffffffff81829a25 7fffffffffffffff
Aug 1 12:58:33 server kernel: [410020.373689] Call Trace:
Aug 1 12:58:33 server kernel: [410020.373711] [<ffffffff81829a25>] schedule+0x35/0x80
Aug 1 12:58:33 server kernel: [410020.373721] [<ffffffff8182cb45>] schedule_timeout+0x1b5/0x270
Aug 1 12:58:33 server kernel: [410020.373732] [<ffffffff810ab0e4>] ? check_preempt_curr+0x54/0x90
Aug 1 12:58:33 server kernel: [410020.373740] [<ffffffff810ab139>] ? ttwu_do_wakeup+0x19/0xe0
Aug 1 12:58:33 server kernel: [410020.373749] [<ffffffff810ab29d>] ? ttwu_do_activate.constprop.90+0x5d/0x70
Aug 1 12:58:33 server kernel: [410020.373760] [<ffffffff8182a483>] wait_for_completion+0xb3/0x140
Aug 1 12:58:33 server kernel: [410020.373767] [<ffffffff810ac0b0>] ? wake_up_q+0x70/0x70
Aug 1 12:58:33 server kernel: [410020.373777] [<ffffffff8109b23d>] flush_work+0x10d/0x1c0
Aug 1 12:58:33 server kernel: [410020.373785] [<ffffffff810974b0>] ? destroy_worker+0x90/0x90
Aug 1 12:58:33 server kernel: [410020.373794] [<ffffffff8109b425>] __cancel_work_timer+0xa5/0x1d0
Aug 1 12:58:33 server kernel: [410020.373804] [<ffffffff813d2571>] ? exact_lock+0x11/0x20
Aug 1 12:58:33 server kernel: [410020.373815] [<ffffffff815573ff>] ? kobj_lookup+0x10f/0x160
Aug 1 12:58:33 server kernel: [410020.373823] [<ffffffff8109b583>] cancel_delayed_work_sync+0x13/0x20
Aug 1 12:58:33 server kernel: [410020.373831] [<ffffffff813d34b8>] disk_block_events+0x78/0x80
Aug 1 12:58:33 server kernel: [410020.373841] [<ffffffff81249417>] __blkdev_get+0x67/0x460
Aug 1 12:58:33 server kernel: [410020.373849] [<ffffffff81249c7d>] blkdev_get+0x12d/0x340
Aug 1 12:58:33 server kernel: [410020.373859] [<ffffffff81249f62>] blkdev_open+0x82/0xd0
Aug 1 12:58:33 server kernel: [410020.373868] [<ffffffff8120acdf>] do_dentry_open+0x1ff/0x310
Aug 1 12:58:33 server kernel: [410020.373876] [<ffffffff81249ee0>] ? blkdev_get_by_dev+0x50/0x50
Aug 1 12:58:33 server kernel: [410020.373884] [<ffffffff8120be74>] vfs_open+0x54/0x80
Aug 1 12:58:33 server kernel: [410020.373893] [<ffffffff81217adb>] ? may_open+0x5b/0xf0
Aug 1 12:58:33 server kernel: [410020.373902] [<ffffffff8121b657>] path_openat+0x1b7/0x1330
Aug 1 12:58:33 server kernel: [410020.373912] [<ffffffff813fd656>] ? sprintf+0x56/0x70
Aug 1 12:58:33 server kernel: [410020.373923] [<ffffffff8121d9c1>] do_filp_open+0x91/0x100
Aug 1 12:58:33 server kernel: [410020.373932] [<ffffffff8122b256>] ? __alloc_fd+0x46/0x190
Aug 1 12:58:33 server kernel: [410020.373940] [<ffffffff8120c248>] do_sys_open+0x138/0x2a0
Aug 1 12:58:33 server kernel: [410020.373949] [<ffffffff8120c3ce>] SyS_open+0x1e/0x20
Aug 1 12:58:33 server kernel: [410020.373957] [<ffffffff8182db32>] entry_SYSCALL_64_fastpath+0x16/0x71
Aug 1 12:58:33 server kernel: [410020.373992] INFO: task btrfs-transacti:2886 blocked for more than 120 seconds.
Aug 1 12:58:33 server kernel: [410020.374135] Not tainted 4.4.0-31-generic #50-Ubuntu
Aug 1 12:58:33 server kernel: [410020.374241] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Aug 1 12:58:33 server kernel: [410020.374393] btrfs-transacti D ffff8801290479f8 0 2886 2 0x00000000
Aug 1 12:58:33 server kernel: [410020.374404] ffff8801290479f8 00000c3496194000 ffff880129c10dc0 ffff880128385280
Aug 1 12:58:33 server kernel: [410020.374413] ffff880129048000 ffff88012ec96d00 7fffffffffffffff ffffffff8182a220
Aug 1 12:58:33 server kernel: [410020.374422] ffff880129047b58 ffff880129047a10 ffffffff81829a25 0000000000000000
Aug 1 12:58:33 server kernel: [410020.374431] Call Trace:
Aug 1 12:58:33 server kernel: [410020.374441] [<ffffffff8182a220>] ? bit_wait+0x60/0x60
Aug 1 12:58:33 server kernel: [410020.374450] [<ffffffff81829a25>] schedule+0x35/0x80
Aug 1 12:58:33 server kernel: [410020.374457] [<ffffffff8182cb45>] schedule_timeout+0x1b5/0x270
Aug 1 12:58:33 server kernel: [410020.374537] [<ffffffffc0468ff0>] ? extent_write_cache_pages.isra.31.constprop.51+0x370/0x3d0 [btrfs]
Aug 1 12:58:33 server kernel: [410020.374547] [<ffffffff8182a220>] ? bit_wait+0x60/0x60
Aug 1 12:58:33 server kernel: [410020.374556] [<ffffffff81828f54>] io_schedule_timeout+0xa4/0x110
Aug 1 12:58:33 server kernel: [410020.374565] [<ffffffff8182a23b>] bit_wait_io+0x1b/0x70
Aug 1 12:58:33 server kernel: [410020.374573] [<ffffffff81829dcd>] __wait_on_bit+0x5d/0x90
Aug 1 12:58:33 server kernel: [410020.374585] [<ffffffff8118d04b>] wait_on_page_bit+0xcb/0xf0
Aug 1 12:58:33 server kernel: [410020.374595] [<ffffffff810c3ce0>] ? autoremove_wake_function+0x40/0x40
Aug 1 12:58:33 server kernel: [410020.374604] [<ffffffff8118d163>] __filemap_fdatawait_range+0xf3/0x160
Aug 1 12:58:33 server kernel: [410020.374615] [<ffffffff8118d1e4>] filemap_fdatawait_range+0x14/0x30
Aug 1 12:58:33 server kernel: [410020.374680] [<ffffffffc0462e22>] btrfs_wait_ordered_range+0x72/0x110 [btrfs]
Aug 1 12:58:33 server kernel: [410020.374746] [<ffffffffc048c7ae>] btrfs_wait_cache_io+0x5e/0x1f0 [btrfs]
Aug 1 12:58:33 server kernel: [410020.374756] [<ffffffff811ebada>] ? kmem_cache_alloc+0x1ca/0x1f0
Aug 1 12:58:33 server kernel: [410020.374812] [<ffffffffc04328ce>] btrfs_write_dirty_block_groups+0xae/0x2b0 [btrfs]
Aug 1 12:58:33 server kernel: [410020.374872] [<ffffffffc04c052d>] commit_cowonly_roots+0x218/0x2c2 [btrfs]
Aug 1 12:58:33 server kernel: [410020.374932] [<ffffffffc04470f6>] btrfs_commit_transaction+0x576/0xa90 [btrfs]
Aug 1 12:58:33 server kernel: [410020.374992] [<ffffffffc0442229>] transaction_kthread+0x229/0x240 [btrfs]
Aug 1 12:58:33 server kernel: [410020.375051] [<ffffffffc0442000>] ? btrfs_cleanup_transaction+0x570/0x570 [btrfs]
Aug 1 12:58:33 server kernel: [410020.375060] [<ffffffff810a0808>] kthread+0xd8/0xf0
Aug 1 12:58:33 server kernel: [410020.375068] [<ffffffff810a0730>] ? kthread_create_on_node+0x1e0/0x1e0
Aug 1 12:58:33 server kernel: [410020.375077] [<ffffffff8182decf>] ret_from_fork+0x3f/0x70
Aug 1 12:58:33 server kernel: [410020.375084] [<ffffffff810a0730>] ? kthread_create_on_node+0x1e0/0x1e0
Aug 1 12:58:33 server kernel: [410020.375108] INFO: task nfsd:3428 blocked for more than 120 seconds.
Aug 1 12:58:33 server kernel: [410020.375233] Not tainted 4.4.0-31-generic #50-Ubuntu
Aug 1 12:58:33 server kernel: [410020.375339] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Aug 1 12:58:33 server kernel: [410020.375491] nfsd D ffff880067e8fb00 0 3428 2 0x00000000
Aug 1 12:58:33 server kernel: [410020.375501] ffff880067e8fb00 00000000512560cb ffff880129c11b80 ffff880129eeb700
Aug 1 12:58:33 server kernel: [410020.375510] ffff880067e90000 ffff8800a44249f0 ffff8800a4424800 ffff8800a44249f0
Aug 1 12:58:33 server kernel: [410020.375519] 0000000000000001 ffff880067e8fb18 ffffffff81829a25 ffff8800a89e37a0
Aug 1 12:58:33 server kernel: [410020.375528] Call Trace:
Aug 1 12:58:33 server kernel: [410020.375538] [<ffffffff81829a25>] schedule+0x35/0x80
Aug 1 12:58:33 server kernel: [410020.375597] [<ffffffffc0445fb3>] wait_current_trans.isra.21+0xd3/0x120 [btrfs]
Aug 1 12:58:33 server kernel: [410020.375607] [<ffffffff810c3ca0>] ? wake_atomic_t_function+0x60/0x60
Aug 1 12:58:33 server kernel: [410020.375667] [<ffffffffc04478db>] start_transaction+0x2cb/0x4c0 [btrfs]
Aug 1 12:58:33 server kernel: [410020.375727] [<ffffffffc0447ae8>] btrfs_start_transaction+0x18/0x20 [btrfs]
Aug 1 12:58:33 server kernel: [410020.375790] [<ffffffffc045d6f8>] btrfs_sync_file+0x238/0x3b0 [btrfs]
Aug 1 12:58:33 server kernel: [410020.375803] [<ffffffff8124112b>] vfs_fsync_range+0x4b/0xb0
Aug 1 12:58:33 server kernel: [410020.375836] [<ffffffffc05bc04d>] nfsd_vfs_write+0x14d/0x380 [nfsd]
Aug 1 12:58:33 server kernel: [410020.375870] [<ffffffffc05c81c4>] nfsd4_write+0x1a4/0x200 [nfsd]
Aug 1 12:58:33 server kernel: [410020.375903] [<ffffffffc05ca13a>] nfsd4_proc_compound+0x38a/0x660 [nfsd]
Aug 1 12:58:33 server kernel: [410020.375931] [<ffffffffc05b6e78>] nfsd_dispatch+0xb8/0x200 [nfsd]
Aug 1 12:58:33 server kernel: [410020.375986] [<ffffffffc05671cc>] svc_process_common+0x40c/0x650 [sunrpc]
Aug 1 12:58:33 server kernel: [410020.376036] [<ffffffffc0568593>] svc_process+0x103/0x1c0 [sunrpc]
Aug 1 12:58:33 server kernel: [410020.376063] [<ffffffffc05b68cf>] nfsd+0xef/0x160 [nfsd]
Aug 1 12:58:33 server kernel: [410020.376089] [<ffffffffc05b67e0>] ? nfsd_destroy+0x60/0x60 [nfsd]
Aug 1 12:58:33 server kernel: [410020.376097] [<ffffffff810a0808>] kthread+0xd8/0xf0
Aug 1 12:58:33 server kernel: [410020.376105] [<ffffffff810a0730>] ? kthread_create_on_node+0x1e0/0x1e0
Aug 1 12:58:33 server kernel: [410020.376113] [<ffffffff8182decf>] ret_from_fork+0x3f/0x70
Aug 1 12:58:33 server kernel: [410020.376121] [<ffffffff810a0730>] ? kthread_create_on_node+0x1e0/0x1e0
Aug 1 12:58:33 server kernel: [410020.376178] INFO: task smartctl:31187 blocked for more than 120 seconds.
Aug 1 12:58:33 server kernel: [410020.376311] Not tainted 4.4.0-31-generic #50-Ubuntu
Aug 1 12:58:33 server kernel: [410020.376417] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Aug 1 12:58:33 server kernel: [410020.376569] smartctl D ffff880100973c88 0 31187 31186 0x00000000
Aug 1 12:58:33 server kernel: [410020.376579] ffff880100973c88 0000000000000000 ffffffff81e11500 ffff88001aeb6040
Aug 1 12:58:33 server kernel: [410020.376588] ffff880100974000 ffff880035426180 0000000000000000 0000000000000000
Aug 1 12:58:33 server kernel: [410020.376596] ffff880100973cc0 ffff880100973ca0 ffffffff81829a25 ffff880035ace4d8
Aug 1 12:58:33 server kernel: [410020.376605] Call Trace:
Aug 1 12:58:33 server kernel: [410020.376615] [<ffffffff81829a25>] schedule+0x35/0x80
Aug 1 12:58:33 server kernel: [410020.376632] [<ffffffffc0032dcb>] megasas_issue_blocked_cmd+0x11b/0x200 [megaraid_sas]
Aug 1 12:58:33 server kernel: [410020.376642] [<ffffffff810c3ca0>] ? wake_atomic_t_function+0x60/0x60
Aug 1 12:58:33 server kernel: [410020.376657] [<ffffffffc003a10e>] megasas_mgmt_fw_ioctl+0x3de/0xad0 [megaraid_sas]
Aug 1 12:58:33 server kernel: [410020.376675] [<ffffffffc003a9cb>] megasas_mgmt_ioctl_fw.isra.25+0x1cb/0x230 [megaraid_sas]
Aug 1 12:58:33 server kernel: [410020.376690] [<ffffffffc003aca8>] megasas_mgmt_ioctl+0x28/0x40 [megaraid_sas]
Aug 1 12:58:33 server kernel: [410020.376698] [<ffffffff81220c0f>] do_vfs_ioctl+0x29f/0x490
Aug 1 12:58:33 server kernel: [410020.376707] [<ffffffff8121c944>] ? putname+0x54/0x60
Aug 1 12:58:33 server kernel: [410020.376715] [<ffffffff8120c2cf>] ? do_sys_open+0x1bf/0x2a0
Aug 1 12:58:33 server kernel: [410020.376723] [<ffffffff81220e79>] SyS_ioctl+0x79/0x90
Aug 1 12:58:33 server kernel: [410020.376731] [<ffffffff8182db32>] entry_SYSCALL_64_fastpath+0x16/0x71
Aug 1 12:58:38 server kernel: [410026.028995] sd 2:2:0:0: tag#16 megasas: RESET cmd=0 retries=0
Aug 1 12:58:38 server kernel: [410026.029013] megaraid_sas 0000:01:00.0: [ 0]waiting for 17 commands to complete
Aug 1 12:58:43 server kernel: [410031.048670] megaraid_sas 0000:01:00.0: [ 5]waiting for 17 commands to complete
Aug 1 12:58:48 server kernel: [410036.068305] megaraid_sas 0000:01:00.0: [10]waiting for 17 commands to complete
Aug 1 12:58:54 server kernel: [410041.088123] megaraid_sas 0000:01:00.0: [15]waiting for 17 commands to complete
Aug 1 12:58:59 server kernel: [410046.107942] megaraid_sas 0000:01:00.0: [20]waiting for 17 commands to complete
...
 
Zuletzt bearbeitet:
Hab mir den M5104 bestellt und in mein P9X79 Pro eingebaut. Ich komme beim booten aber leider nur zu diesem Screen hier:
LSI.jpg

Hat jemand eine Idee, was das Problem sein könnte?
 
Am BIOS des Mainboards, am BIOS des Controllers, am PCIe-Steckplatz, usw..

Spiel mal das neuste BIOS auf das Mainboard auf und steck den Controller in einen anderen PCIe-Slot :)


Der Boot-Vorgang beim Standard-BIOS des Controllers dauert meist sehr lange ...
 
Zuletzt bearbeitet:
Steckplätze habe ich schon 2 unterschiedliche versucht.
Das neuste BIOS ist drauf (4801).

Ist das denn das Standard-BIOS des Controllers? Ich dachte da müsste IBM oder sowas stehen :P

EDIT: Ach du Kacke.... jetzt tut sich was. Das dauert ja tatsächlich fast eine Minute. Und ich dachte schon der Controller ist hinüber! :d
 
Zuletzt bearbeitet:
Zum Glück :shot:
 
Hab jetzt mal 2x 1TB 840 Pro drangehängt. Laut synthetischen Benchmarks war das Ergebnis jetzt nicht so berauschend.
Aber ich glaube das täuscht (mit AS SSD getestet).

Ich will zu den 2x1TB SSDs noch eine 2TB hinzufügen. Ich überlege jetzt gerade, wie ich es das am Besten handhabe.
Im Endeffekt möchte ich gerne 4TB im RAID0 haben, aber das wird wohl nicht gehen, oder doch?

Hatte dann überlegt die 2TB einzeln am LSI zu betreiben und sie über einen mount point in das RAID einzuhängen, oder gibt es
einen eleganteren Weg?
 
Ja das dauert ewig... :d
Ich habe mir auch ein aktuelles Bios geflasht will diesen beknackten delay wieder los werden. Ich hatte das damals wie folgt geändert gehabt:
MegaOEM -AdpSettings Write -f MyM5014.ini -a0
Da dann das delayPOST in der erzeugten Datei auf 0 setzen und die Datei zurück spielen mit:
MegaOEM -AdpSettings Read -f MyM5014.ini -a0

Leider finde ich aber das MegaOEM Programm nicht mehr. Brauche das für Linux. Hat das jemand? Oder geht das auch mit MegaCLI?

@Stevie: Ggf musst du das WriteBack erzwingen damit du vernünftige Schreibraten hast. Vielleicht auch Blockgröße anpassen. Eine SSD hat ja meist 8K Blöcke
 
Zuletzt bearbeitet:
Das MegaOEM ist im SAS2108.zip von der Startseite mit dabei. Mit der MegaCLI geht das leider nicht.

Ich glaube der Controller kommt einfach nicht so gut mit SSDs klar. Bin eh am überlegen, ob ein neueres System mit mehr Datendurchsatz nicht mehr Sinn ergibt.
 
@Stevie1
Ja der Controller ist nicht der beste/schnellste für SSDs. Haben schon einige Leute (auch hier im Thread wenn mich nicht alles täuscht) gestestet. Bedenke daß der Controller von Ende 2009/Anfang 2010 ist. Für SSDs eignen sich somit aktuellere Controller besser (LSI hat ja inzwischen 2 neue Generationen dieser Controller Chips rausgebracht), oder gerade wenn Du Raid 0 oder 10 nutzen willst bieten sich hier vielleicht auch Soft RAID Lösungen an, je nach Betriebssystem/Filesystem etc. Entweder direkt an SATA 6GB Anschlüssen am Mainboard oder mit HBA Karten.
 
@Stevie: danke für den Tipp. Ok das ist leider die Windows Version. Muss ich mir einen Dos Bootstick bauen...

Ich finde auch die SSDs laufen am Mainboardcontroller besser als am Raidcontroller. Hab da aber selber noch nicht viele Tests gemacht. Wenn man wirklich schnelle SSDs haben will, dann sollte man entweder eine PCIe SSD nehmen oder eine mit einem besseren M.2
Andererseits vermutlich wird man den Unterschied ob die SSD am Controller hängt oder am SATA Port vom Board kaum merken.
Zu Softraid Lösungen, die nutzen wir an Linux System in unserer Firma. Funktionieren da ganz gut. Von dem Softraid von Windows würde ich dagegen die Finger lassen. Davon rät selbst Microsoft ab ;)

Nachtrag zu meinen Abstürtzen. Hab jetzt das Board getauscht. Läuft jetzt seit einer knappen Woche. Ggf hatte das PCIe Interface einen Schuss weg.b jetzt das Board getauscht. Läuft jetzt seit einer knappen Woche. Ggf hatte das PCIe Interface einen Schuss weg.
 
Zuletzt bearbeitet:
An meinem 5014 hängen 6x4TB im Raid 5. Wie bekomme ich heraus welche Festplatte welche Nummer hat? Die Festplatte Nr.5 (also die letzte, geht ja von 0 los) hat er letzt rausgeschmissen wegen Fehler, konnte auf der Platte zwar ein Rebuild machen aber er meckert dauernt dass die Festplatte bald wieder ausfällt.

Ich will die nun mit einer neuen ersetzen. Wie am besten vorgehen? Einfach die fehlerhafte Festplatte raus und die neue rein, dann rebuild? Oder gibts ne Möglichkeit die Fehlerhafte auf die neue zu spiegeln und dann erst die alte raus, damit wären zusätzliche Ausfälle beim Rebuild kein Problem.
Wie bekomme ich genau raus welche Festplatte an welchem Kabel hängt? Im Storage Manager gibts ja die Funktion "Locate Drive", aber irgendwie passiert da gar nichts wenn ich drauf klick ;)
 
Hi WaDenKraMpF!
Die "Locate Drive" Funktion ist für ein Gehäuse/Drive Enclosure gedacht welches Status LEDs besitzt. Dann blinkt dort das Lämpchen. Hast Du die Platten in einem normalen Gehäuse ohne diese Lämpchen pro Drive bringt es Dir natürlich nichts.
Am einfachsten sollte es sein wenn Du Dir einfach die Seriennummer des Laufwerks aus dem Storage Manager aufschreibst und danach auf der Platte suchst. Soviel ich weiß haben alle 3,5" Platten der letzten Jahre diese auf der Stirnseite (gegenüber den Anschlüssen) mit einem Strichcode aufgeklebt um diese bei geeigneten Gehäusen schnell zu finden.

Normalerweise -> alte raus -> neue rein - Rebuild.
Je nachdem wie alt die Platten schon sind bzw. was die schon an Workload haben bzw. aus der selben Charge sind etc. stehen die Chancen jedoch verhältnismäßig hoch daß bei einem Rebuild eventuell auch eine andere Platte aus dem Verbund ausfällt/Probleme macht. Im schlimmsten Fall verliert man dadurch das komplette Array. Deswegen setzen viele Leute auf Raid 6 da dort noch eine gewisse zusätzliche Sicherheit besteht.
Ich will Dir jetzt keine Panik machen, mit ziemlicher Sicherheit geht bei dem Rebuild nichts schief, aber wie gesagt die Chancen stehen deutlich höher als wenn da alle neue Platten wären bei der Dir eine ausgefallen ist.
Ein aktuelles Backup der wichtigsten Daten sollte also auf jeden Fall da sein.

Theoretisch könnte ein sektorbasierendes Klonen der defekten Platte auf eine neue und dann die Einbindung dieser in das Raid funktionieren. Praktisch macht das aber wohl nicht viel Sinn denn einen Consistency Check oder gar Scrub sollte bzw. wird der Controller wohl machen um zu sehen ob die Daten noch alle okay sind. Das geht zwar schneller als ein Rebuild, belastet das Array aber ähnlich.

Ich hoffe ich habe jetzt keinen Blödsinn geschrieben und es korrigiert mich wer falls ich wo falsch liege.
 
Hallo Zusammen,
ich möchte mein esxi Server mit weiteren SATA HDD/SSD ausrüsten und hab dazu ein M5014 auf Ebay gekauft.

Ich will weder RAID noch brauch ich zwingend Spin-Down.

Bin etwas verwirrt über die vielen Firmware-Möglichkeiten IBM, Lenovo, LSI usw..worin ist der unterschied ? Welche aktuelle Firmware empfehlt Ihr mir für meinen Zweck ?

Danke, grüße
 
Hab mich jetzt entschieden die aktuelle LSI Firmware von hier zu nehmen.

Hoffe dass haut hin :hail:
 
Guten Abend,

ich betreibe meinen M5015 auf einem SuperMicro Board mit VMware 6.0U2. Es funktioniert alles ohne Probleme mit nur einer Einschränkung.
Ich habe auf dem ESXi Server den passenden Treiber installiert und die aktuellen CIM Provider. Somit kann ich meinen Controller über den Megaraid Storage Manager verwalten. Allerdings funktioniert eine Raiderweiterung nicht da die Option "Modify Drive Group" ausgegraut ist. Hat jemand hier ggf. eine Idee wodran es liegen kann?
 
kurze Frage, macht es Sinn für die "configured drives" den powersave mode bzw. spinndown zu konfigurieren?!
Oder brauchen die HDDs dann zu lange zu spinnup und das System hängt dementsprechend ständig?
 
Hallo,

ich bin günstig an einen D2616 gekommen und möchte nun meinen altgedienten 9650SE in Rente schicken. Bevor ich mich an irgendwelche „Crossflash-Versuche“ wage, wollte ich mich mit dem neuen Controller ein bisschen vertraut machen und habe daher einfach mal einen „Test-Array“ bestehend aus vier Platten im Raid-Level 5 aufgesetzt, den ich unter Windows 7 teste. Ich habe dem Controller dazu die neuste LSI-Firmware von der Fujitsu-Homepage (Version 12.15.0-0239 - 2.130.403-4660) verpasst und verwende den Treiber Version 6.701.04.00. Insgesamt bin ich bisher eigentlich - trotz der etwas längeren Bootzeit gegenüber dem 9650SE - ganz zufrieden.

Jedoch gibt es eine Sache, die mich nervt, da ich sie so vom 9650SE nicht kenne:

Jedes Mal, wenn ich einen „Neustart“ des BS durchführe, um z. B. eine Treiberinstallation abzuschließen, verhält sich der neue Controller so, als würde ich den PC herunterfahren und schaltet alle vier Festplatten ab. Da das System aber nur rebootet, werden die Festplatten dementsprechend nur wenige Sekunden später wieder neu gestartet. Dies ist zum einen zeitaufwendig und zum anderen glaube ich kaum, dass diese Prozedur den Festplatten auf Dauer gut tut. Irgendwie scheint der D2616 nicht zwischen einem Reboot und einem Shutdown des Systems zu unterscheiden. Beim 9650SE gab es diesbezüglich keine Probleme, denn bei einem Reboot blieben die Festplatten einfach an.

Meine Frage ist nun: Kann man dieses Verhalten ändern? Im „MegaRAID Storage Manager“ habe ich dazu leider nichts gefunden. Könnte es helfen, wenn ich den Controller zu einem LSI 9260-8i o. ä. crossflashe?
 
Hallo,

ich konnte mein Problem mit der LSI-Firmware Version 12.12.0-0045 vom 03/04/11 lösen. Sie ist zwar relativ alt, beinhaltet dafür aber noch zusätzlich die „Power saving options“ für die "configured drives".

Der Spindown der Festplatten beim Neustart/Reboot des OS wurde anscheinend mit der Firmwareversion 12.12.0-0048 vom 04/15/11 eingeführt bzw. eingeschleppt. Im Changelog heißt es:

„LSIP200167677 (CO) FW should issue STANDBY IMMEDIATE command to SATA disks during shutdown from OS“

Ich habe keine Ahnung wofür das tatsächlich gut sein soll, aber mich nervt es einfach tierisch, wenn die Festplatten bei jedem Neustart bzw. Reboot des OS erst ausgeschaltet werden und dann wieder hochfahren müssen. Da der Controller von Hause aus - trotz „delayPOST = 0“ - nicht gerade schnell bootet, wird die Aktualisierung oder Neuinstallation von Treibern mit den neueren Firmwareversionen, die nach 12.12.0-0045 erschienen sind, für mich zu einem Geduldsspiel, bei dem ich meistens verliere. ;)

Na ja, wie auch immer. Mit der Firmwareversion 12.12.0-0045 läuft der Controller jetzt so, wie ich mir das vorstelle. Wenn innerhalb der nächsten Tage keine neuen Probleme auftreten, beende ich die Testphase und werde den D2616 in den „Regeldienst“ übernehmen.
 
sehr schön, manchmal muss man dann doch der eigene Pionier werden,
weil noch niemand diesen Weg gegangen ist.

Glückwunsch
 
Ich habe mal eine Frage zu diesem Sata3 Controller:

Ich habe für ein älteres MSI P55-GD65 Mainboard ab 2011 für einen PCIe SATA3 Controller suche
einen Sata3 Controller, damit ich meine Crucial SSD Sata3 mit optimalen Lesen und schreiben Speed (550MB/s lesen u. 520MB/s schreiben) betreiben kann

Hier ist ein Link zu diesem Motherboard mit den Spezifikationen:

https://de.msi.com/Motherboard/P55GD65/Specification

Ich habe neue Crucial SSD Sata3 und ich möchte sie mit voller Leistung verwenden, mindestens 5GB/s.

Ich habe bereits 2 PCIe Sata3 mit ASMedia 1061 Chipsatz getestet und habe sie in einem PCIe Slot 16 (PCIe 2.0) und nur 370 MB/s
von der SSD gelesen und schreiben, mehr kommt da nicht. Ich habe mit ATTO Benchmark 3.05 unter Windows10 getestet.
Ich lese im Netz, dass es mit dem Lane des PCIe auf dem Mainboard zu tun hat, ist das so ?

Sata3, die SSD kann 520 MB / Sekunde unter echten Sata3 Ports und 550 schreiben MB / Sekunde. In meinem neuen Mainboard MSI z97
kann die gleiche Crucial SSD (520GB) volle Geschwindigkeit.

Kann dieser IBM 5014 Controller in dem Motherboard MSI P55-GD65 mehr als nur ca. 370 MB/s lesen und schreiben erreichen ?

ich möchte nur 1 SSD anschliessen, also der Controller soll da normal nicht als RAID laufen, geht das ?

Kann ich solch eine Karte auch preisgünstig erwerben und was muss ich beachten, welche Version usw. ? Wird er auch für MacOS Sierra 10.12.6 unterstützt
in einem Hackintosh ?

Danke für Informationen und Hilfe.
 
Zuletzt bearbeitet:
Da scheint dann wohl der PCIe Slot nicht direkt angebunden zu sein,
Da wo PCIe 2.0 draufsteht, ist nicht zwingend die Geschwindigkeit von PCIe 2.0 drin.
Dann kommt es noch darauf an, wieviele PCIe Lanes die Karte hat

PCIe 2.0 X1 kann theoretisch 500 MB/s Abzüglich Verwaltungsoverhead erscheint mit 370 MB/s da gar nicht mal so schlecht

Ja, der IBM 5014 kann das, da mit PCIe 2.0 X8 versorgt (4 GB/s), ist aber auch ein Hardware-Raid Controller
 
@Dicke-Quick Danke für deine Info.. aber wie du schreibst macht dann der IBM 5040 auch nicht gerade mehr als 370 MB/s und dann 400 MB/s.
Das lohnt dann auch nicht. Ich war der Meinung das auch eventuell mit einem PCI 2.0 vielleicht 450 oder 500 MB/s erreicht werden können.

Schade um die schöne schnelle Crucial SSD die ja in meinem anderen PC (MSI Z97-G43 Motherboard) und echten internen Sata3 Controller
520 schreiben und 550 MB/s lesen bringt. In dem neueren PC habe ich schon 2 SSD mit je 960 GB drin.

Ich wollte gerne den alten P55-GD65 weiter benutzen oder ein ähnliches Board kaufen, das GD85 hat nämlich 2 Stück Sata3 drin.
Da bräuchte ich dann keinen Prozessor und RAM noch kaufen, als wenn ich wieder ein neues Board kaufe.

Weisst du vielleicht wer ein MSI P55-GD85 hat ?

Danke
 
Zuletzt bearbeitet:
Anmelden, um zu antworten.
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh