Mixed mdadm-raid5 mit 4k Sektor-Platte?

Zitat von whitegrey

kann sowas nicht auch daran liegen, dass es keine RAID-grade/Enterprise Platten waren (Eco/Green-Serie)

das merkst nur an der Performance und sollten eigentlich kein Problem sein wenn man sich an ein paar regln hält (im grunde nimm am ehesten 7200U/min platten und wenns eine WD ist stell den TLER Wert höher)

deshalb verwend ich keine WD im Raid bei anderen Herstellern hab ich das ganze noch nicht gehört. Ich selber hab Samsung F4 (eben auch welche mit 5400 U/min) im NAS mit einem RaidZ und da seit am guten halben Jahr keinerlei Probleme

mdadm wartet meines wissens 30sec, Hardware Raid Controller irgendwo zw. 15 und 30sec

Da ich aktuell nur BSD als OS bei den Rechnern mit Raid habe und dort GEOM zum Einsatz kommen würde hab ich dort ZFS am laufen.
GEOM hat einsehr kurzes Timeout, irgend was unter 5sec

Ist es aber nicht so das TLER nur bei Raidplatten überhaupt eingeschalten ist (ok nur bei read, write ist immer aus) und bei Desktop Platten sowieso aus ist da es dort keinen Sinn macht?

Zitat von COLOSSUS

@EG: Dann kauf bitte einfach irgendeinen tollen proprietaeren Controller, wo du dann glaubst, dass du damit superpipifein und problemlos "fahren" wirst, und verschone uns alle mit deinen Quenglereien und einfach voellig unfundierten Aussagen. Die Mehrzahl deiner Probleme sind direktes Resultat deiner eigenen Inkomptenz am Geraet.

Weißt Colo ich schätz dein Wissen um die Open-Source Welt ja wirklich, aber diese militante schwarz-weiß Sicht gepaart mit sofortiger trotzartiger Reaktion ist echt nur mehr mühsam! Manchmal erinnerst mich einfach zu stark an diverse Fallobstjünger, wenns wiedermal ihre Wurmbehausung in Gefahr sehen...
Völlig entgleisen und sofort den Gegenüber massiv diskreditieren.

Keine Technologie ist perfekt.

Die Krankheitsgeschichte meines Raids ist schnell erklärt:

9.2.10 und 4.7.10 ist jeweils eine Platte "removed" worden, weil ich beim 1. mal an einem Kabel angekommen bin (ja so wackelig sind die Dinger! -.-) und beim zweiten Mal ein Kabel sich beim Transport des Geräts gelöst hat.
Beide Male wars ein Aufwand von mehreren Stunden, die Platten wieder ins Raid zu bekommen, weil sie - selbst nach reboots - noch immer irgendwo busy waren, obwohl lsof und fuser etwas anderes indizierten. Keiner (auch du nicht Colo) wusste eine Lösung, außer "turn it off and on again...versuch mal ohne angesteckte Platte zu booten".
Irgendwann hat sich mdadm dann mehr zufällig als bewusst dazu entschieden die Platten doch anzunehmen. War nicht wirklich nachvollziehbar wieso es dann beim 50. Mal nach ~4 reboots plötzlich doch funktioniert hat.

20.10.2010: mdadm kickt fast gleichzeitig zwei Platten aus dem Raid5. Grund war (vermutlich!) eine schlechte Verbindung (SATA-Stecker sind wirklich übel!) und zusätzlich ein Plattenfehler. Da hilft auch kein Monitoring!
Damals hab ichs mehr aus Zufall wieder hinbekommen indem ich das Raid "gewaltsam" dazu gezwungen hab sich zu assemblen. Es war ja eigentlich bis auf wenige Bytes clean. Nach einigen wenigen fs-Fehlern, die nicht weiter wichtig waren (Backup usw.) war alles wieder in Ordnung. Selbst du lieber Colo hast nur gestaunt, dass das so geklappt hat und hast mich schon an die Mailing-Liste verwiesen.

30.10.2011: Der Server wurde am Vortag heruntergefahren, weil ihn an diesem WE ohnehin keiner brauchen wird und das File System kam nach dem Boot komplett zerschossen wieder hoch. Kein unsauberes Aushängen, generell keine Eingaben abgesehen von "init 0".

Klarerweise auch kein Stromausfall (was ja sehr oft tötlich endet)...selbst wenn hätt ich dafür eine USV. Die hat mir nicht nur einmal den Server vor größerem Schaden bewahrt!

Mit einigen kleineren Vorfällen, welche mit minimalem Datenverlust verbunden waren, ist wäre das jetzt der erste große und insgesamt dritte Datenverlust seit 2 Jahren.

Immer warens plötzlich auftretende Fehler. Der Server steht auf einem Regal im Abstellkammerl...die Katzen kommen nicht ran und die werte Dame des Hauses war zu diesem Zeitpunkten auch nicht zu gegen.

Natürlich haben die Probleme auch viel mit der Customer-Hardware zu tun, das will ich gar nicht leugnen. Ist halt auch ein Unterschied in Qualität und auch Preis.
Trotzdem raubts einem gleich viele Stunden, wenn eine Platte mal wieder aus dem Raid fällt und ihr nach diversen erfolglosen checks mit badblocks, Herstellertools und Co. der Einlass ins Raid - scheinbar - völlig grundlos verwehrt wird.

Hab oft in Foren/Wikis gelesen...ubuntu, ubuntuusers, debian, mdadm, alles was google halt noch so ausgespuckt hat...man muss _IRRSINNIG_ aufpassen, wenn dort User vermeindlich helfen wollen. Da stehen oft Sachen drinnen, die unweigerlich das komplette Raid zerstören würden.
Von meinen nicht wenigen Tripps durchs Internet hab ich folgende Erfahrung mitgenommen: Auf 1 vernünftige Quelle kommen mindestens 10 schlechte.

Was ich damit sagen will:
mdadm ist wohl ein gutes Stück Software, aber nicht perfekt. Die Community verbreitet viel falsche Information. Deshalb ist es sehr schwer bei einem Fehler schnell zu einer Lösung zu kommen. Ganz im Gegenteil, kann man bei blindem Vertrauen sogar sein Raid noch weiter zerstören.
Ergo ist der Administrationsaufwand für so ein Raid sehr hoch.

Dafür ist das Raid wirklich sehr performant, wenns denn mal fehlerfrei läuft.

Für mich ist die ML bzw. der dev des Projekts halt nicht die primäre Ansprechperson bei Problemen im Betrieb.
Sehr schön, dass bei md offenbar ein so engagnierter dev dahinter steckt...wusste ich nicht! Würd mir auch etwas seltsam vorkommen diesen Herren der md entwickelt mit meinen Problemen zu behelligen.
Der Weg dorthin wäre für mich nur dann gerechtfertigt, wenn von dem Raid bzw. den Daten wirklich etwas abhängen würde. Unwiederbringliche Daten, Geld, Firma, Existenz...aber dann läuft ohnehin im Grundkonzept der Datenhaltung etwas schief, wenn alles von einem Raid abhängt.

Ergo habe ich diesen Schritt bisher immer ausgeschlossen.

Für den Rest hast Post. Das gehört nicht hier her.