staging.inyokaproject.org

So, grundsätzlich wär's das erstmal von meiner Seite aus. Nochmal Korrekturlesen und Links prüfen wäre hilfreich, ich hab bestimmt was übersehen ☺ Vielleicht noch ein paar Grundgedanken der Überarbeitung:

Die Anleitung an sich sollte nur das enthalten, was im Normalfall wirklich nötig ist. Sonder- und Spezialfälle, Unterschiede bei alten Versionen etc. sollten die Anleitung nicht für normale Nutzer verkomplizieren und stehen daher weiter unten in extra Abschnitten.

Vielen sehr veralteten Kram habe ich ganz rausgeschmissen. Den Kernel muss man z.B. schon lange nicht mehr veranlassen, die Partitionstabellen neu zu lesen und von fdisk sollte man inzwischen wirklich die Finger lassen, parted ist schon lange der Standard-Diskeditor bei Ubuntu. Wenn Ihr also glaubt, es würde etwas fehlen, dann prüft doch bitte, ob das wirklich noch aktuell ist. Ansonsten fügt weiter unten einen neuen Abschnitt für ältere Versionen hinzu statt es in die normale Anleitung zu schreiben. Ich denke, zu detailierte Anleitungen können auch abschreckend wirken.

So ganz glücklich bin ich zwar nicht, ich finde es sieht immer noch alles recht aufgebläht aus, aber hoffentlich ist es besser als vorher. Am meisten Bauchschmerzen bereitet mir der Abschnitt MDADM. Ich hab den Inhalt zwar auf den atkuellen Stand gebracht, finde aber, das ist zu viel für einen Wiki-Artikel. Das hat schon viel von Manpage kopieren. Persönlich würde ich den Abschnitt rausschmeissen und auf die Manpage verweisen wollen. Was sagt Ihr dazu?

Nonymus schrieb:

So, grundsätzlich wär's das erstmal von meiner Seite aus.

Schoen zu hoeren. Angesichts der Komplexitaet des Themas wird ein Review durch das Wiki-Team etwas dauern - also keine Panik ☺

Fettschrift wird grossteils nichtWikikonform verwendet. s. http://wiki.ubuntuusers.de/Wiki/Syntax#Textformatierung

sonst m.E. schön!

Eine sehr gelungene Ueberarbeitung ☺ Eine Frage habe ich aber: warum wird im Abschnitt "Anlegen eines RAID" GPT benutzt? Gibt es dafuer zwingende Gruende?

aasche schrieb:

Eine Frage habe ich aber: warum wird im Abschnitt "Anlegen eines RAID" GPT benutzt? Gibt es dafuer zwingende Gruende?

Mit herkömmlicher Partitionstabelle (MBR) sind maximal 2 TB große Partitionen möglich, bei entsprechenden Platten muss man also eh GPT verwenden (falls man nicht stückeln will). Bei kleineren Platten könnte man natürlich auch MBR nutzen. GPT funktioniert aber da genauso, daher wollt ich den Abschnitt nicht unnötig zweiteilen.

Wollte's möglichst einfach und gleichzeitig so zukunftssicher wie möglich halten. 3 TB Platten gibt's inzwischen auch im Consumer-Bereich und GPT verdrängt (langsam, aber sicher) MBR als Standardformat.

Nonymus schrieb:

Mit herkömmlicher Partitionstabelle (MBR) sind maximal 2 TB große Partitionen möglich, bei entsprechenden Platten muss man also eh GPT verwenden (falls man nicht stückeln will). Bei kleineren Platten könnte man natürlich auch MBR nutzen. GPT funktioniert aber da genauso, daher wollt ich den Abschnitt nicht unnötig zweiteilen.

Wollte's möglichst einfach und gleichzeitig so zukunftssicher wie möglich halten. 3 TB Platten gibt's inzwischen auch im Consumer-Bereich und GPT verdrängt (langsam, aber sicher) MBR als Standardformat.

Verstaendlich und nachvollziehbar. Trotzdem wuerde ich an dieser Stelle eine Experten-Box einbauen, die die genannten Gruende enthaelt und den Parameter fuer MBR enthaelt.

Was passt parted mit "-a optimal" denn noch an, wenn man Start und Endsektor fest vorgibt?

Hallo,

mir ist eine IMO relativ wichtige Konfigurationsmöglichkeit für die mdadm.conf über den Weg gelaufen, die im Wiki nicht erwähnt ist. Man kann in der mdadm.conf auch definieren, das der Kernel selbst nach den Partitionen suchen soll. So ist der Nachteil, das durch umstecken usw. das Raid nicht mehr aufgebaut werden kann, wieder wett gemacht. Das steht zwar in der mit mdadm mitgelieferten Beispieldatei sogar drin aber zumindest ich habe es überlesen. Daher würde ich gern einen Hinweis auf diese möglichkeit einfügen.

bei mir sieht das dann so aus:

DEVICE partitions
ARRAY /dev/md0 metadata=1.2 spares=1 name=nastom:0 UUID=fb3ba739:61be1362:4fd60b4c:3232560f

Wenn ihr einverstanden seid, trag ich das an passender Stelle ein.

btw. Mein NAS baut sein RAID gerade wieder auf, da ich Trottel eine Platte falsch angesteckt hatte. Passiert mir jetzt nicht noch mal.

hannemann schrieb:

mir ist eine IMO relativ wichtige Konfigurationsmöglichkeit für die mdadm.conf über den Weg gelaufen, die im Wiki nicht erwähnt ist. Man kann in der mdadm.conf auch definieren, das der Kernel selbst nach den Partitionen suchen soll. So ist der Nachteil, das durch umstecken usw. das Raid nicht mehr aufgebaut werden kann, wieder wett gemacht.

Hoert sich interessant - bitte mit Erklaerung und unter Angabe der getesteten Ubuntu-Version (falls weder 12.04 noch 13.04) in den Artikel einbauen.

hannemann schrieb:

Man kann in der mdadm.conf auch definieren, das der Kernel selbst nach den Partitionen suchen soll.

Ähm, mit Verlaub, aber IMO geschieht das automatisch, sofern man nichts anderes konfiguriert:

# by default (built-in), scan all partitions (/proc/partitions) and all
# containers for MD superblocks. alternatively, specify devices to scan, using
# wildcards if desired.

Bei mir:

[    1.934879] md: raid6 personality registered for level 6
[    1.936719] md: raid5 personality registered for level 5
[    1.938500] md: raid4 personality registered for level 4
[    2.156823] md/raid:md0: device sda1 operational as raid disk 0
[    2.158670] md/raid:md0: device sdb1 operational as raid disk 1
[    2.160509] md/raid:md0: device sdc1 operational as raid disk 2
[    2.162336] md/raid:md0: device sdd1 operational as raid disk 3
[    2.164136] md/raid:md0: device sde1 operational as raid disk 4
[    2.166250] md/raid:md0: allocated 5332kB
[    2.168095] md/raid:md0: raid level 5 active with 5 out of 5 devices, algorithm 2

Wie man sieht funktioniert die Erkennung des Raid sehr schnell.

Und nein: / liegt nicht auf dem Raid 😀

pepre schrieb:

Ähm, mit Verlaub, aber IMO geschieht das automatisch, sofern man nichts anderes konfiguriert:

Da bin ich ganz bei dir aber ich hab es es in der Beispielkonfigurationsdatei überlesen und im aktuellen Wiki Artikel steht im Beispiel

DEVICE /dev/...

usw.

Dadurch hat es mir nach Einbau einer weiteren Platte das RAID zerlegt. Einen Hinweis darauf, wie man das fixen kann, finde ich nicht ganz unwichtig, gerade wenn man das RAID vor der Überabeitung bereits angelegt hatte. In der Baustellenseite fehlt dieser.

Getestet habe ich die Konfiguration unter 12.04

aasche schrieb:

Verstaendlich und nachvollziehbar. Trotzdem wuerde ich an dieser Stelle eine Experten-Box einbauen, die die genannten Gruende enthaelt und den Paramater fuer MBR enthaelt.

Ich sehe dadurch keinen Mehrwert. Mir ist kein Szenario bekannt, in dem man, zumindest bei den getesteten Versionen, durch MBR einen Vorteil hat oder es erforderlich wäre. "Weil man das früher so gemacht hat und man dran gewohnt ist" wäre für mich kein ausreichender Grund 😉. Falls es gute Gründe gibt wäre ich dann eher für einen weiteren Abschnitt im unteren Teil oder einen Verweis auf einen entsprechenden Artikel über Partitionierung. Sonst bläht sich die Anleitung doch wieder zu einem unleserlichen Gewust auf.

stfischr schrieb:

Was passt parted mit "-a optimal" denn noch an, wenn man Start und Endsektor fest vorgibt?

Parted wird "gewzungen" die Angaben auf korrektes Alignment zu prüfen. Falls die angegeben Werte einem optimalen Alignment widersprechen, meckert parted und fragt, ob es die nicht auf die nächstmöglichen, optimalen Werte anpassen soll. Das macht parted zwar normalerweise auch ohne das man den Parameter extra angibt, aber falls jemand die Warnung ausgeschaltet hat (Konfiguration, selbst kompiliert oder sonstwas), kommt sie eben dann doch. Im Normalfall macht der Parameter also gar nichts, stört aber auch nicht und kann bei Nicht-Standard-Konfigurationen hilfreich sein.

hannemann schrieb:

Da bin ich ganz bei dir aber ich hab es es in der Beispielkonfigurationsdatei überlesen und im aktuellen Wiki Artikel steht im Beispiel

DEVICE /dev/...

usw.

Dadurch hat es mir nach Einbau einer weiteren Platte das RAID zerlegt. Einen Hinweis darauf, wie man das fixen kann, finde ich nicht ganz unwichtig, gerade wenn man das RAID vor der Überabeitung bereits angelegt hatte. In der Baustellenseite fehlt dieser.

Getestet habe ich die Konfiguration unter 12.04

Das hab ich jetzt noch nicht wirklich verstanden. Vielleicht magst du noch mal Schritt für Schritt erklären, wie genau was schief gegangen ist?

Es war früher mal so (10.10, 11.04... irgenwie sowas um den Dreh), dass der Kernel bei der automatischen Erkennung nur Partitionen berücksichtigt hat, deren Partitionstyp auf 0xfd (mbr) steht, bzw. deren raid flag gesetzt ist (bei GPT). Ob das immer noch so ist habe ich nicht getestet.

Nonymus schrieb:

Es war früher mal so (10.10, 11.04... irgenwie sowas um den Dreh), dass der Kernel bei der automatischen Erkennung nur Partitionen berücksichtigt hat, deren Partitionstyp auf 0xfd (mbr) steht, bzw. deren raid flag gesetzt ist (bei GPT). Ob das immer noch so ist habe ich nicht getestet.

Das (RAID autodetect des Kernels) ist was ganz anderes und hat mit mdadm / mdadm.conf nichts zu tun. Die automatische Erkennung macht der Kernel (nur bei msdos fd, nicht bei gpt), und der berücksichtigt solche Dateien nicht.

Wenn der DEVICE Zeile das nötige Device fehlt, fällt mdadm aber auf die Nase, so gesehen eine mögliche Fehlerquelle. Ich habe trotzdem eine DEVICE /dev/sd* Zeile in meiner mdadm.conf, weil man sonst andere Probleme hat. Wenn auch langsame Geräte (floppy, Netzwerk, ...) im Spiel sind dann sucht mdadm dort auch und dementsprechend kann mdadm selbst ziemlich langsam werden beim RAID zusammen basteln. Würde man das Ding jetzt aber in einer VM booten und aus /dev/sda würde plötzlich /dev/vda werden, dann geht nichts mehr. Oder n alter Kernel der noch mit /dev/hda arbeitet...

Man muss eben wissen was man da macht. Für 0815 kann es durchaus überlegenswert sein, die DEVICE einfach wegzulassen. Die Probleme treten ja nur in Sonderfällen auf.

Um zu vermeiden, dass die Festplatten andere Namen bekommen gibt es ja nun schon seit mehreren Jahren die UUIDs oder wenn man garkeine Partitionierung benutzt eben die GeräteID /dev/disk/by-id/...

frostschutz schrieb:

Nonymus schrieb:

Es war früher mal so (10.10, 11.04... irgenwie sowas um den Dreh), dass der Kernel bei der automatischen Erkennung nur Partitionen berücksichtigt hat, deren Partitionstyp auf 0xfd (mbr) steht, bzw. deren raid flag gesetzt ist (bei GPT). Ob das immer noch so ist habe ich nicht getestet.

Das (RAID autodetect des Kernels) ist was ganz anderes und hat mit mdadm / mdadm.conf nichts zu tun. Die automatische Erkennung macht der Kernel (nur bei msdos fd, nicht bei gpt), und der berücksichtigt solche Dateien nicht.

Das stimmt so nicht. Die automatische Erkennung macht immer der Kernel, falls denn die passenden Module auch verfügbar sind. mdadm ist lediglich das userland-tool zu Kommunikation mit dem kernelspace, aka den Modulen und dem md-Teil des Kernels. Zugriff auf die mdadm.conf besteht über die initrd. Aus dem userland stößt mdadm lediglich den Kernel an und sagt "Hier, mach mal". Richtig ist, dass Partitionstyp oder RAID-Flag nur bei Superblock 0.9 eine Rolle spielen.

[...] Wenn auch langsame Geräte (floppy, Netzwerk, ...) im Spiel sind dann sucht mdadm dort auch und dementsprechend kann mdadm selbst ziemlich langsam werden beim RAID zusammen basteln.

Das ist seltsam. Natürlich braucht das Prüfen auf einen Superblock Zeit und in der Summe wird der Boot ohne schneller gehen. Allerdings wird nicht nacheinander auf allen Geräten gesucht und währenddessen alles andere blockiert. Wenn ein neues Gerät erscheint wird darauf nach einem Superblock gesucht. Falls einer gefunden wird, wird ein Vermerk gemacht, dass dieser Teil des md-Device schon da ist. Sobald genügend aufgetaucht sind, wird das md-Device gestartet. Das Raid-Device startet also sobald alle Teil-Geräte dem Kernel bekannt sind, und das ist lange (in Kernel-Maßstäben) bevor er sich mit Network-Devices beschäftigt. Mit traditionellen Floppies sollte sich md gar nicht befassen. Ich könnte mir allerdings vorstellen, dass das bei USB- oder SATA-Floppylaufwerken Probleme geben könnte. Wie sieht deine /proc/partitions aus?

Würde man das Ding jetzt aber in einer VM booten und aus /dev/sda würde plötzlich /dev/vda werden, dann geht nichts mehr. Oder n alter Kernel der noch mit /dev/hda arbeitet...

Das hat nichts mit dem Alter des Kernels zu tun, sondern mit der Anschlussart der Geräte. Geräte an IDE-Controllern kriegen /dev/hdX-Geräte, SCSI/SATA/SAS bekommen /dev/sdX. /dev/vdX ist KVM-spezifisches Gefrickel. vmware oder virtualbox arbeiten mit IDE- oder SCSI-Emulation. In allen drei Fällen gibt's aber kein Problem, wenn man einfach den Standard belässt.

Ich habe trotzdem eine DEVICE /dev/sd* Zeile in meiner mdadm.conf, weil man sonst andere Probleme hat. [...] Man muss eben wissen was man da macht. Für 0815 kann es durchaus überlegenswert sein, die DEVICE einfach wegzulassen. Die Probleme treten ja nur in Sonderfällen auf.

Deswegen wird im Abschnitt über mdadm.conf auch ausdrücklich vor eigenen Änderungen in der Datei gewarnt. Ich denke, nicht nur für "0815" ist es angebracht, da nicht vom Standard abzuweichen. Bis jetzt war's für mich auf keiner Büchse nötig, das zu ändern. Wer das trotzdem möchte, muss eben, wie du sagt, genau wissen was man tut.