Wechseln von OpenSolaris?

[PuckPoltergeist]

Ja und was ist mir Raid5,6 bei btrfs?

Immer noch in Arbeit. Oder glaubst du, das ändert sich über Nacht?

Für mich aber kein professionelles Verhalten

Warum machst du es dann?

 

[ghostadmin]

Wieso ich?

 

[Berniyh]

Ich bin froh, dass es das noch nicht hat, bei den ganzen Problemen, die man damit bekommen kann.

Ich habe auch kein Problem damit, dass das noch nicht implementiert ist. Würde es ohnehin ausschalten.
Für manche Zwecke mag es ganz nett sein, aber im Normalfall braucht man sowas meiner Meinung nach nicht.
Insbesondere als privater Anwender lohnt das meiner Meinung nach nicht, da Festplattenspeicher heutzutage ziemlich billig ist.

Ja und was ist mir Raid5,6 bei btrfs?

Ist meines Wissens in Arbeit.
Ich ziehe ohnehin Raid1 vor, aber wenn unbedingt Raid5 verlangt wird, dann kann man ja immer noch md nehmen. Deshalb sehe ich das momentan nicht als wirklich kritisch an. Bis btrfs wirklich stable ist, würde ich das ohnehin vorziehen.

 

[ghostadmin]

Ja über mdadm das ist leider auch nicht perfekt. Ich hatte schon mehrmals erlebt das eine Platte ausstieg bei Raid1 - so weit normal weils an der Hardware liegt - aber dann nach dem Reboot war plötzlich die andere wieder Master und ich hatte die aktuellen Daten verloren seit dem die Platten das letzte mal gesynced waren.

Und was mir auch passiert ist, als ich die Platte wieder dem Raid hinzufügte machte der keinen Rebuild und sie war sofort Online. Bin mir allerdings nicht sicher ob das daran gelegen haben könnte weil ich die Devices md0 und die Platte in der falschen Reihenfolge angegeben habe

Also quasi so:
mdadm --add /dev/md0 /dev/sda
mdadm --add /dev/sda /dev/md0

 

[Berniyh]

Ja über mdadm das ist leider auch nicht perfekt. Ich hatte schon mehrmals erlebt das eine Platte ausstieg bei Raid1 - so weit normal weils an der Hardware liegt - aber dann nach dem Reboot war plötzlich die andere wieder Master und ich hatte die aktuellen Daten verloren seit dem die Platten das letzte mal gesynced waren.

Da kapiere ich irgendwie das Problem nicht.

Und was mir auch passiert ist, als ich die Platte wieder dem Raid hinzufügte machte der keinen Rebuild und sie war sofort Online. Bin mir allerdings nicht sicher ob das daran gelegen haben könnte weil ich die Devices md0 und die Platte in der falschen Reihenfolge angegeben habe

Auch hier ist mir nicht ganz klar, was du gemacht hast. Wenn die Platte noch die Daten drauf hatte, dann hat er sie evtl. einfach erkannt und ein re-add war die Folge. Das könnte unter Umständen ja schon recht schnell gehen.

mdadm --add /dev/md0 /dev/sda

Da sollte er eigentlich meckern, dass sda kein raid device ist...

Insofern kann das eigentlich nicht daran liegen.

Abgesehen davon ist mdadm ziemlich weit verbreitet und daher gut getestet. Das wird vielerorts auch professionell eingesetzt. Grobe Fehler kann ich mir da wirklich schwer vorstellen (bzw. sollten sehr selten sein).
Ich selbst hatte eigentlich noch nie Probleme damit, aber ok, ich bin ja auch nicht statistisch relevant.

 

[ghostadmin]

Kann vielleicht an der Hardware liegen, eine Platte ist nämlich über USB angesteckt und wird beim boot erst nach MD geladen und dementsprechend fliegt die Platte bei jedem Reboot wieder raus. Habe schon alles mit USB im Kernel aber das hat nichts gebracht.

Das Problem war halt das eine Platte im Betrieb rausflog, dass war die eingebaute IDE Platte. Dann lief einige Zeit nur die USB Platte im Raid. Danach wurde gebootet und die IDE Platte war plötzlich wieder Master ohne das ich irgendwas geändert hätte. Eine Platte die er selbst offline gesetzt hatte, war nach dem Reboot plötzlich wieder online.

Btw. seh ich schon wieder das die IDE Platte gefailed ist, muss erstmal Backup machen

 

[yourgreatestfear]

Ich bezweifle das die Zeile mdadm --add /dev/sda /dev/md0 so ohne Rückmeldung angenommen wurde. Ich glaube also kaum das der Fehler gemacht wurde. Verstehe aber auch nicht wieso man auf eine logische/saubere Befehlssyntax (mdadm /dev/md0 -a /dev/sda) verzichtet.
Das manuelle Adden wäre nur nötig, wenn vorher das Laufwerk sauber removed wurde. Ob Ghostadmin das getan hat ist mir nicht klar. Im Falle des richtigen Partitionstyps der Scheibe wäre es klar das nach Reboot der Spiegel übernimmt solang der Fehler nicht behandelt wurde.
Wenn man sein mdadm allerdings dahingehend konfiguriert hat einmal gekickte Scheiben automatisch wieder reinzulassen ohne sie vorher failed zu flaggen und das berühmte zero-superblock anzuwenden, dann brauch man sich auch nicht wundern wieso kein resync stattfindet.

Entweder hast Du uns vorgenommene Arbeitsschritte vorenthalten oder aber notwendige Arbeitsschritte nach einem Plattenkick ausgelassen. Aus mehrfacher Erfahrung sind verlorene Daten keine Folge eines simplen Ausstiegs einer Platte. Ich glaube eher hier liegt ein Fehler bei der Administration des Arrays und/oder des Wiedereinbindens vor.

BTW: --add kickt nur einen resync an, wenn der array mit per-device superblocks erstellt wurde, ansonsten muss re-add verwendet werden.

Soviele offene Fragen, aber in dem Falle vermute ich den Fehler nicht bei mdadm.

 

[Berniyh]

Naja, ein Raid über USB ist auch ein bisschen eine Herausforderung. Bezweifle, dass das mit fs-internem Raid wirklich besser funktioniert.

 

[ghostadmin]

Ich bezweifle das die Zeile mdadm --add /dev/sda /dev/md0 so ohne Rückmeldung angenommen wurde.

ist euch schon aufgefallen das ihr beide es verdreht habt
werde in Zukunft einfach --manage vor md0 schreiben, dann kann man nichts verdrehen

Wenn man sein mdadm allerdings dahingehend konfiguriert hat einmal gekickte Scheiben automatisch wieder reinzulassen

wer macht sowas? oder ist das default?

Ich hab den gleichen Fall aber schon wieder und das sieht jetzt so aus:
Number Major Minor RaidDevice State
0 0 0 0 removed
1 8 5 1 active sync /dev/sda5
2 3 5 - faulty spare /dev/hda5

Und ich weiß genau, wenn ich jetzt boote, ist hda5 wieder online. Wenn ich jetzt hda5 adden möchte, kommt die Meldung das sie busy ist.

BTW: --add kickt nur einen resync an, wenn der array mit per-device superblocks erstellt wurde, ansonsten muss re-add verwendet werden.

da komme ich jetzt nicht ganz mit. Du meinst soviel wenn man eine komplett neue Platte hat ohne Magicblock nimmt man readd?

 

[yourgreatestfear]

ist euch schon aufgefallen das ihr beide es verdreht habt
werde in Zukunft einfach --manage vor md0 schreiben, dann kann man nichts verdrehen

Wir haben da gar nix verdreht. Deinerein hat geschrieben:

mdadm --add /dev/md0 /dev/sda
mdadm --add /dev/sda /dev/md0

Das du mit Angabe von --add als ersten Parameter sowieso im Managemode landest macht die Angabe von manage absolut überflüssig, aber nur solange zuerst die Arraydevice angegeben wird und daraufhin die hinzuzufügende Partition. Wenn du zukünftig "mdadm --add /dev/sda --manage /dev/md0" schreiben willst, dann viel Glück. Nicht nur das man sich dabei nen Schreibkrampf holen könnte, ich hab diese Variante auch noch nie in irgendeiner Doku gesehen. Ob das funzt weiss ich dazu schomal gar nicht.

wer macht sowas? oder ist das default?

Defaultverhalten ist von vielen Faktoren abhängig, zB ob wiBitmaps benutzt werden (ich würd bei USB-Platten dazu immer raten), persistente superblocks existieren usw. Da wir keine Ahnung haben wie dein Array erstellt wurde, ist das alles Glaskugellesen. Deine Probleme resultieren wohl eher aus dem falschen Wiederhinzufügen der Scheibe. Zumindest hast du bisher nicht erwähnt ob du vor dem add sauber das Teil faultest und removed hast. Wenn ich folgendes lese ...


Number Major Minor RaidDevice State
0 0 0 0 removed
1 8 5 1 active sync /dev/sda5
2 3 5 - faulty spare /dev/hda5

... bin ich da fast sicher dass Du dies nicht getan hast. Denn eine removed number 0, eine sda active und eine faulty spare sind schomal ein device zuviel in einem simplen RAID1 .

da komme ich jetzt nicht ganz mit. Du meinst soviel wenn man eine komplett neue Platte hat ohne Magicblock nimmt man readd?

Wann man add oder re-add verwendet hängt davon ab wie das Array erstellt wurde. Siehe dazu Manpages create/build und all die Options jeweils.

 

[ghostadmin]

Wir haben da gar nix verdreht. Deinerein hat geschrieben:

soso

Zitat von yourgreatestfear Beitrag anzeigen
Ich bezweifle das die Zeile mdadm --add /dev/sda /dev/md0

und

mdadm --add /dev/md0 /dev/sda
Da sollte er eigentlich meckern, dass sda kein raid device ist...

Das du mit Angabe von --add als ersten Parameter sowieso im Managemode landest macht die Angabe von manage absolut überflüssig, aber nur solange zuerst die Arraydevice angegeben wird und daraufhin die hinzuzufügende Partition. Wenn du zukünftig "mdadm --add /dev/sda --manage /dev/md0" schreiben willst, dann viel Glück.

wieso unterstellst du mir eigentlich dauernd Dinge die ich nicht tue?
mit --manage und --add kann ichs mir halt besser merken

Defaultverhalten ist von vielen Faktoren abhängig, zB ob wiBitmaps benutzt werden (ich würd bei USB-Platten dazu immer raten), persistente superblocks existieren usw. Da wir keine Ahnung haben wie dein Array erstellt wurde, ist das alles Glaskugellesen. Deine Probleme resultieren wohl eher aus dem falschen Wiederhinzufügen der Scheibe. Zumindest hast du bisher nicht erwähnt ob du vor dem add sauber das Teil faultest und removed hast. Wenn ich folgendes lese ...


Number Major Minor RaidDevice State
0 0 0 0 removed
1 8 5 1 active sync /dev/sda5
2 3 5 - faulty spare /dev/hda5

... bin ich da fast sicher dass Du dies nicht getan hast. Denn eine removed number 0, eine sda active und eine faulty spare sind schomal ein device zuviel in einem simplen RAID1 .

du vertauscht da 2 Sachen. Bei dem Beispiel oben gehts nur darum das wenn ich booten würde plötzlich die andere Platte master ist ohne das ich irgendwas adde oder sonstiges eingebe sondern einfach nur ein reboot erfolgt mehr nicht. Wo Number 0 herkommt ist aber ne gute Frage, ist mir vorher nicht aufgefallen.

Und ausser add wurde an dem Raid nie was anderes gemacht. Mit create erstellt, keine Ahnung was du mit Glaskugel meinst ...

Wenn eine Platte auf Faulty steht und man sie mit add wieder hinzufügt dann sollte auf jeden Fall ein rebuild erfolgen und die Platte nicht einfach Online ohne Prüfung erscheinen. Wieso soll ich da vorher ein remove machen wenn sich die Devicenr nicht ändert und ich die Platte nicht austausche?

Wann man add oder re-add verwendet hängt davon ab wie das Array erstellt wurde. Siehe dazu Manpages create/build und all die Options jeweils.

Prima wenn man anstatt ja/nein gleich auf Manpages verweist
Dort steht das re-add notwendig ist wenn das Device removed wurde und das ist nicht der Fall. Und Magicblock haben die Platten ebenfalls weil das raid mit create und nicht mit build erstellt wurde

 

[yourgreatestfear]

mdadm --add /dev/md0 /dev/sda
Da sollte er eigentlich meckern, dass sda kein raid device ist...

Genau da wird nicht gemeckert, weil mdadm --add <raiddevice> <hinzuzufügende partition> die korrekte reihenfolge ist. Lese dazu bitte das Manual, falls Du mir nicht glauben willst. Und eben weil diese Befehlssyntax nicht für jeden logisch erscheint, empfehl ich Leuten die selten mdadm benutzen zur Syntax mdadm <raiddevice> -a <hinzuzufügende partition> !!!

wieso unterstellst du mir eigentlich dauernd Dinge die ich nicht tue?
mit --manage und --add kann ichs mir halt besser merken



du vertauscht da 2 Sachen. Bei dem Beispiel oben gehts nur darum das wenn ich booten würde plötzlich die andere Platte master ist ohne das ich irgendwas adde oder sonstiges eingebe sondern einfach nur ein reboot erfolgt mehr nicht. Wo Number 0 herkommt ist aber ne gute Frage, ist mir vorher nicht aufgefallen.

Und ausser add wurde an dem Raid nie was anderes gemacht. Mit create erstellt, keine Ahnung was du mit Glaskugel meinst ...

Wenn eine Platte auf Faulty steht und man sie mit add wieder hinzufügt dann sollte auf jeden Fall ein rebuild erfolgen und die Platte nicht einfach Online ohne Prüfung erscheinen. Wieso soll ich da vorher ein remove machen wenn sich die Devicenr nicht ändert?

Faulty hat man zu removen, bevor man an Add überhaupt denkt. Das du dies nicht getan hast, ist leicht herauslesbar aus dem magischen 3. Laufwerk. Ich unterstelle also zu recht, dass Deinerein etwas nicht getan hat.

Prima wenn man anstatt ja/nein gleich auf Manpages verweist

Weil es keine Ja/Nein- Antwort geben konnte in dem Fall! Es hatt auch nix mit komplett neuer Platte zu tun. Es gibt RAID mit und ohne persistent Superblocks! Magic überlassen wir mal lieber Harry Potter

PS: Re-add ist optional zu add um bei RAIDkonfigs mit wiBitmaps ein komplettes Reconstruct zu verhindern, aber nur wenn das RAID mit build erstellt wurde und somit das Defaultverhalten anders ist bei add. Remove eines Faulty wirst du immer machen müssen! Sonst landest Du wieder bei Fehleinträgen wie deinem 0. Device!

 

[ghostadmin]

Genau da wird nicht gemeckert, weil mdadm --add <raiddevice> <hinzuzufügende partition> die korrekte reihenfolge ist. Lese dazu bitte das Manual, falls Du mir nicht glauben willst. Und eben weil diese Befehlssyntax nicht für jeden logisch erscheint, empfehl ich Leuten die selten mdadm benutzen zur Syntax mdadm <raiddevice> -a <hinzuzufügende partition> !!!

lies bitte oben nochmal um was es geht

Faulty hat man zu removen, bevor man an Add überhaupt denkt. Das du dies nicht getan hast, ist leicht herauslesbar aus dem magischen 3. Laufwerk. Ich unterstelle also zu recht, dass Deinerein etwas nicht getan hat.

glaube ich nicht, weil ich das schon zig mal gemacht habe nachdem die Platte nach dem Reboot "weg" also faulty war und add hatte jedes mal den rebuild angestartet. Remove macht man wenn man die Platte gegen eine andere austauscht.

Weil es keine Ja/Nein- Antwort geben konnte in dem Fall! Es hatt auch nix mit komplett neuer Platte zu tun. Es gibt RAID mit und ohne persistent Superblocks! Magic überlassen wir mal lieber Harry Potter

ich glaube das hatte ich in Erinnerung von "bad magic number in super block" aber egal

 

[yourgreatestfear]

Du schreibst von Datenverlust nach Ausfall einer einzelnen Platte, postest mdstats mit fehlerhaften Deviceanzahlen und -states und machst remove nur, wenn eine Platte wirklich physisch getauscht wird ... das Deinerein immernoch so beratungsresistent ist verwundert mich dann doch.

Den berühmten 3Satz -f -r -a findet man in jedem besseren Tutorial. Wie du offensichtlich schon selbst erlebt hast, kann der Ausfall der Platte auch bewirken, dass sie nicht als eine Altbekannte die nur mal im Urlaub war erkannt wird. Und da der ganze Spaß nur ein Einzeiler ist als Befehlseingabe muss man sich auch nicht wehren dagegen.

Viel Erfolg noch bei der Datenrettung, ich halt mich ab nun zurück.

 

[PuckPoltergeist]

Wieso ich?

Wenn ich dich mal zitieren darf:

hab ich nur kurz überflogen aber nachdem ne Platte ausfällt da noch dedup ausmachen, zu defragmentieren und wer weiß noch alles, da ist das kein Wunder. Und jedes Filesystem kann mal kaputt gehen.

 

[ghostadmin]

Da komme ich nicht mit ... Was soll ich "machen" ?
.
EDIT :
.

Du schreibst von Datenverlust nach Ausfall einer einzelnen Platte, postest mdstats mit fehlerhaften Deviceanzahlen und -states und machst remove nur, wenn eine Platte wirklich physisch getauscht wird ... das Deinerein immernoch so beratungsresistent ist verwundert mich dann doch.

Den berühmten 3Satz -f -r -a findet man in jedem besseren Tutorial. Wie du offensichtlich schon selbst erlebt hast, kann der Ausfall der Platte auch bewirken, dass sie nicht als eine Altbekannte die nur mal im Urlaub war erkannt wird. Und da der ganze Spaß nur ein Einzeiler ist als Befehlseingabe muss man sich auch nicht wehren dagegen.

Viel Erfolg noch bei der Datenrettung, ich halt mich ab nun zurück.

Im Tutorial geht man auch davon aus das die Platte wirklich kaputt ist und nicht wie bei mir nur beim booten zu spät geladen wird wegen USB und deswegen failed. Ich empfinde daher den remove nur als zusätzliches Risiko.

Wenn ich die IDE Platte gegen eine andere tausche dann braucht es einen Remove, soviel hab ich schon verstanden ...

Ich gebe zu der Post weiter früher war etwas verwirrend weil ich 2 Probleme auf einmal schrieb und wahrscheinlich noch immer nicht alle kapieren was ich meinte

 

[PuckPoltergeist]

Da komme ich nicht mit ... Was soll ich "machen" ?

Du hast die Bugs von ZFS schön geredet.

Das Interessante dabei ist (jetzt nicht unbedingt auf dich bezogen, ghostadmin), bei Linux schreien gleich alle immer Frickelware, Kinderspielzeug etc. Bei Solaris heißt es, selber Schuld, wenn man so etwas mit dem Dateisystem macht.

 

[Berniyh]

Das Interessante dabei ist (jetzt nicht unbedingt auf dich bezogen, ghostadmin), bei Linux schreien gleich alle immer Frickelware, Kinderspielzeug etc. Bei Solaris heißt es, selber Schuld, wenn man so etwas mit dem Dateisystem macht.

... und bei Windows spricht man von einem Feature.

 

[ghostadmin]

Naja Nobody is perfect. Auch bei Netapp gibts so manch tödliches Feature

Man kennt halt oft nur die eigenen Erfahrungen die aber im Endeffekt überhaupt nichts repräsentieren.

 

[Nero24]

Darf ich fragen, wieso hier in diesem Thread ein so aggressiver Unterton herrscht? Mich interessiert das Thema auch, aber der Ton hier macht das Lesen nicht unbedingt zum Vergnügen. Und wenn ich das schon sage, wie werden das wohl erst Besucher empfinden, die via Google-Suchbegriff hier ins Forum geraten sind...

 

[PuckPoltergeist]

Naja Nobody is perfect. Auch bei Netapp gibts so manch tödliches Feature

Right, aber die verlangen Geld für ihre Produkte, und das nicht gerade wenig. Deshalb bekommen die auch richtig böse auf die Finger, wenn sie so etwas machen.

Man kennt halt oft nur die eigenen Erfahrungen die aber im Endeffekt überhaupt nichts repräsentieren.

Deshalb auch die Links ins OpenSolaris-Forum. Die Bugs, die dort manche Leute beschrieben haben, finde ich schon erschreckend. Und deshalb verstehe ich dein "da ist das kein Wunder" auch nicht.

 

[ghostadmin]

Naja ich wollte nur sagen das genau dieser Post für mich nicht repräsentativ war ungeachtet von den anderen Threads dort.

 

[Mogul]

Hi,

ist dieses mdadm irgendeine äquivalent zu den Metasets in Solaris ? Das hat, auf die schnelle geschaut, nichts mit ZFS zu tun ?

Wir bauen 100% aller Server OS seitig mit Metasets zusammen. Sprich metadbs auf s7 (20-50mb reichen uns).
metainit d10 1 1 Platte2 , metainit d20 1 1 Platte2, metainit d1 -m d10, metatach d1 d20

erstelle metadevice d10 (1 1 = 1 Platte, kein stripe/mirror)
erstelle metadevice d20
erstelle metadevice d1, definiere es als mirror und hänge d10 dazu
hänge d20 an d10. Hier wird alles von d10 auf d20 gesynct.

die vfstab müsste da noch angepasst werden. Zwischendurch mit einem mir gerade nicht bekannten Befehl metaroot setzen....

Da ist mir noch nie etwas falsch gesynct

 

[PuckPoltergeist]

Hi,

ist dieses mdadm irgendeine äquivalent zu den Metasets in Solaris ? Das hat, auf die schnelle geschaut, nichts mit ZFS zu tun ?

Ohne jetzt die Solaris Metasets überhaupt zu kennen, wage ich jetzt mal die Behauptung, dass die beiden nicht wirklich miteinander vergleichbar sind.

mdadm ist nur das Administrationstool für den md-RAID Treiber im Linux-Kernel. Der ermöglicht es, verschiedene RAID-Konfigurationen über block devices zu erstellen. Wobei block devices wirklich sehr weit gefasst sind. Das können komplette Platten, Partitionen, Floppies oder gar schon erstellte RAIDs sein.

 

[yourgreatestfear]

@Mogul
mdadm selbst ist nur ein Tool um 'multiple disks' zu verwalten. Dabei beschränkt sich das ganze auf die Zuordnung von physischen Partitionen zu selbst erstellten Gerätedateien und auf die Erzeugung von redundanten Datenströmen zu den Partitionen. Dabei kann natürlich jede physische Partition schon eine selbst erstelle Gerätedatei sein.

Sobald eine Abstrahierung von Partitionen in logische Volumes nötig wird, setzt der LVM auf.
In Linux/Unix ist es also eine klare Trennung. Auf der mdadm-Seite die Administration vorhandener Partitionen bzw. Erzeugung redundanter Datenströme und auf der LVM-Seite Administration der Umleitung von Datenströmen auf logische Laufwerke.

Es ist als eine Geschichte, die nix mit ZFS zu tun hat. "Falsch syncen" gibt es automatisch bei mdadm auch nicht, wenn dann hat der User eingegriffen und dies erzwungen.

@Nero24
Wir sind alles erwachsene Leut hier. Wenn ich so alte Haudegen wie Ghostadmin hier etwas zu harsch angehe, dann lag es wohl daran, dass in einem Gebiet gewildert wurde, wo ich überzeugt bin mich sehr gut auszukennen. Ich entschuldige mich hiermit bei Ihm und allen sensiblen Mitlesern für die Kollateralschäden.
Sein Problem ist im neuen Thread ab jetzt auch besser aufgehoben.