staging.inyokaproject.org

chrischdi hat sich bei mir gemeldet. Er wird wohl in nächster Zeit nicht mehr am Artikel arbeiten. Das größte Problem sieht er darin, dass es noch keine stable version gibt.

Ich habe den Artikel als verlassen markiert. Falls sich je sonst noch jemand zutraut, den Artikel zu bearbeiten – gerne! 😉

Kuttel Daddeldu schrieb:

Ich habe den Artikel als verlassen markiert.

Baustelle reaktiviert und von "zfs" in "ZFS on Linux" umbenannt. Aufgrund der geringen Nutzerzahlen und des Entwicklungsstatus wird die Fertigstellung allerdings dauern.

Kann Lucid raus oder Serverrelevanz? 'Gruss

frustschieber schrieb:

Kann Lucid raus oder Serverrelevanz? 'Gruss

Ubuntu 10.04 entfernt.

Hallo,

ich wurde zum Editieren des zfs-Artikels hinzugezogen, bin aber

• unerfahren als Doku-Schreiber

• derzeit wegen Urlaubs meines Partners allein

• im Prozess, mich da einzufuchsen

Mir fiel auf, daß die in Bearbeitung befindliche Version sichtbar geschaltet ist. ☹

Kann jemand die Fassung vor den Eingriffen bitte wiederherstellen, so daß ich erstmal nur auf der Kopie weitermachen kann?

Danke

Hi datenninja,

der Artikel ist komplett in der Baustelle, du kannst also nach Belieben den Artikel verändern. Baustellenartikel sind für alle sichtbar, aber eben nicht im offiziellen Wiki und es führt auch kein einziger Link auf einen Baustellenartikel (außer wenn es sich um eine Überarbeitung handelt, dann aber nur von dem Ursprungsartikel).

Gruss Lasall

Und du musst auch keine Angst haben, etwas 'kaputt' zu machen - das Wiki hat ein Versionsmanagement, mit dem man vorhergehende Versionen wiederherstellen kann.

Stefan

Danke sehr... beruhigend (wenigstens teilweise). Inzwischen sehe ich es ein: eine solide Planung würde das Arbeiten sicher erleichtern. Mache das erstmal lokal bei mir. Gibt es auch Tools für die lokale Bearbeitung des Wiki-Textes?

Hi datenninja,

schaue, ob unter Wiki/Hilfsmittel (Abschnitt „Editoren“) etwas für dich dabei ist. Inyokaedit ist das einzige Programm, das (offline-)Support für Wikidarstellung hat.

Gruss Lasall

Nochmal DANKE! Trifft den Nagel auf den Kopf.

Das kann jetzt 'ne Weile dauern... aber so ist es mir lieber, u.a. weil es vermeidet, die Versionsverwaltung mit irrelevanten Zwischenständen zu "belästigen".

Mein allererster Aktikel (wer kennt nicht das Gefühl?)

Die KATASTROPHE hat ihren Lauf genommen!

Zwar dürften die Spuren der Legasthenie nicht so stark ins Gewicht fallen. Aber - obwohl ich schon VIEL weg gelassen habe - ist das Ganze womöglich ausgeufert und ich wünsche mit konstruktive Kritik, bevor das Alles in den Schredder muß. 😉

Und ich kipp mir jetzt einen oder höre wenigstens "Relax! Dont do it..."

Hi.

Danke schonmal für deine Mühe. Ich konzentriere mich mal auf den Inhalt, die Formatierung haben die Wikinger besser drauf.

Unter:

Planung¶

Weiterhin hat es sich bewährt, einige Überlegungen VOR der Datenmigration anzustellen, wie von den ZFS-Funktionen, insbesondere von der Vererbung, im konkreten Anwendungsfall bestmöglicher Nutzen gewonnen werden kann.

Diese Vererbung wird nirgendwo nochmal erklärt. Entweder vorher erklären oder nacher und von hier aus darauf verlinken. Oder weglassen.

Unter:

Installation¶

Etwas wenig. Ein Link auf Paketquellen freischalten/PPA und die Kommandozeile zum Installieren wäre gut.

Unter:

Best Practices¶

Man erzeuge (reale) Pools immer mit den Schaltern -o ashift=12 -d /dev/disk/by-id. Das vermeidet der Fall, daß man in Zukunft nicht zu einer AF-Platte wechseln kann, während es unempfindlich gegen die grundsätzlich unbekannte Reihenfolge macht, mit der die Festplatten im System erscheinen.

den Fall? Und bei AF-Platte gleiches wie bei Vererbung. (Erklärung?)

Soweit erstmal, ich lese nacher weiter ...

Cool! Bliebe dies die einzige Kritik, könnte ich schon mal entspannen. 😉

stfischr schrieb:

Hi.

Danke schonmal für deine Mühe. Ich konzentriere mich mal auf den Inhalt, die Formatierung haben die Wikinger besser drauf.

Unter:

Planung¶

Weiterhin hat es sich bewährt, einige Überlegungen VOR der Datenmigration anzustellen, wie von den ZFS-Funktionen, insbesondere von der Vererbung, im konkreten Anwendungsfall bestmöglicher Nutzen gewonnen werden kann.

Diese Vererbung wird nirgendwo nochmal erklärt. Entweder vorher erklären oder nacher und von hier aus darauf verlinken. Oder weglassen.

Im Konzept steht: Wer (etwa für viele Benutzer) viele "Teile" (hier als Oberbegriff für Dateisysteme und Volumes verwendet) zu verwalten hat, wird es zu schätzen wissen, daß diese "Teile" hierarchisch strukturiert werden können und ihre Eigenschaften sozusagen vererbbar sind. Man könnte z.B. für Nutzergruppen, Datenarten, -verwendungszwecke sinnvolle Voreinstellungen treffen, die über solche Dinge entscheiden wie Speicherplatzhöchstgrenzen (Quota), -mindestbedarf (Reservation), Kompression, Schreibschutz, Empfindlichkeit für Klein/Großbuchstaben bei Dateinamen, Cachingverhalten. Alle Möglichkeiten aufzuzählen würde diesen Rahmen sprengen.

Unter:

Installation¶

Etwas wenig. Ein Link auf Paketquellen freischalten/PPA und die Kommandozeile zum Installieren wäre gut.

Das habe ich aus 2erlei Gründen weggelassen:

• Es ist die Kurzfassung im Beispiel angegeben.

• In dem Link auf die FAQ steht es auch noch.

• Und... wer SO WAS installiert, sollte damit schon klar kommen. Für DAU's ist das nichts!

Unter:

Best Practices¶

Man erzeuge (reale) Pools immer mit den Schaltern -o ashift=12 -d /dev/disk/by-id. Das vermeidet der Fall, daß man in Zukunft nicht zu einer AF-Platte wechseln kann, während es unempfindlich gegen die grundsätzlich unbekannte Reihenfolge macht, mit der die Festplatten im System erscheinen.

den Fall? Und bei AF-Platte gleiches wie bei Vererbung. (Erklärung?)

Beide Hinweise nehme ich dankend an.

Soweit erstmal, ich lese nacher weiter ...

datenninja schrieb:

Das kann jetzt 'ne Weile dauern... aber so ist es mir lieber, u.a. weil es vermeidet, die Versionsverwaltung mit irrelevanten Zwischenständen zu "belästigen".

Boah eyh, da haste Dir jetz aba wirklich Zeit jelassen. 😉 😛

Bei der Installation fehlt die PPA-Warnung wg. Fremdquellen. Ich weiß leider nicht, wie man die einbaut, aber das können wohl die WIKI-Profis machen.

Man erzeuge (reale) Pools immer mit den Schaltern -o ashift=12 -d /dev/disk/by-id. Das vermeidet der Fall, daß man in Zukunft nicht zu einer AF-Platte wechseln kann, während es unempfindlich gegen die grundsätzlich >unbekannte Reihenfolge macht, mit der die Festplatten im System erscheinen.

Wo stammt denn dieser Rat her? den kann ich nicht auf der angegebenen Seite finden. Wenn der von woanders oder von dir ist, muss das gekennzeichnet werden - IMHO.

Was ist denn nun genau Deduplizierung, das solltest Du nach Möglichkeit erkären.

Den Text Warnung/Vorbehalte habe ich noch mal neu fromuliert, weil ich deine Übersetzungen für zu sehr verkürzt halte.

Der Sinn dieser Warnungen ist keinesfalls jemanden von der Verwendung von ZFS abzuschrecken. Als Speicheradministrator der seinen ZFS Speicher Server plant, muss man sich dieser Dinge jedoch bewußt sein, damit es einen nicht kalt erwischt - und ohne seine Daten. Wenn man diese Warnungnen nicht im beherzigt, muss man mit Datenverlust rechnen.

* Ein 'zfs destroy' kann eine Unterbrechung des Zugriffs auf andere Dateisysteme verursachen. Ein 'zfs-destroy' wird jede Datei in einem Dateisystem dieses Speicherpools berühren. Je größer das Dateisystem um so länger wird dies dauern, und es wird alle möglichen IOPS der Platten nutzen, um dies auszuführen. Demzufolge wird, wenn das zerstören des Dateisystems 2 Stunden dauert, potentiell 2 Stunden lang kein Zugriff auf die anderen Dateisysteme möglich sein.

* Debian und Ubuntu starten den NFS-Daemon nicht ohne einen gültigen export in /etc/exports. Also muß man entweder einen Dummy-export anlegen oder das /etc/init.d/nfs script anpassen.

* Debian und Ubuntu nutzen einen parallelisierten Bootprozeß. Dadurch ist die Reihenfolge der  Init-Scripts nicht mehr sichergestellt. Dies führt zu Problemen beim einbinden von ZFS Dateisystemen zum Bootzeitpunkt. In Debian und Unbunto muss die /etc/init.d/.legacy-bootordering Datei dahingehend geändert werden, dass /etc/init.d/zfs als erstes script indiesem runlevel gestartet wird. (Anm.: höchstwahrscheinlich nicht mehr aktuell, da ZFS jetzt ein eigenes Paket mountall mitinstalliert.)

* Man sollte niemals einen Pool bauen, der Dateien/Volumes eines anderen Pools benutzt. Dies verursacht alle möglichen Schwierigkeiten.

* Wenn man ZVOLs erzeugt, sollte deren blocksize identisch oder ein Vielfaches der blocksize sein, mit der man später formatieren will. Sonst kann dies zu Performance-Problemen führen.

* Wenn das kernel module 'zfs' geladen wird, muss man sicherstellen, das ein Maximalwert für ARC festgelegt ist. Wenn viele 'zfs-send' Befehle oder 'snapshots' ausgeführt werden, werden diese Daten zwischen gespeichert. Wenn man den Wert nicht festgelegt hat wird das RAM nach und nach gefüllt, bis der kernel OOM Killer ausführt, und das System wieder reagiert.
So führt der Eintrag {{{options zfs zfs_arc_max=2147483648} } } in der datei /etc/modprobe.d/zfs.conf zu einer Beschränkung auf 2 GB  RAM für ARC. (Anm: Aufgrund von RAM-Fragmentierung können dennoch bis zum Doppelten dieses Wertes benötigt werden!)

Ob die Formatierung so gut aussieht, weiß ich nicht, jedenfalls wäre das mein Virschlag für den Text.

So, das wars erst mal. Einige kleine Änderungen an der Seite habe ich schon eingefügt. Aber sonst finde ich den Artikel Klasse, prima Arbeit.

Stefan

lionlizard schrieb:

datenninja schrieb:

Das kann jetzt 'ne Weile dauern... aber so ist es mir lieber, u.a. weil es vermeidet, die Versionsverwaltung mit irrelevanten Zwischenständen zu "belästigen".

Boah eyh, da haste Dir jetz aba wirklich Zeit jelassen. 😉 😛

Ha, der hat ja noch Humor!

Bei der Installation fehlt die PPA-Warnung wg. Fremdquellen. Ich weiß leider nicht, wie man die einbaut, aber das können wohl die WIKI-Profis machen.

Gerne!

Man erzeuge (reale) Pools immer mit den Schaltern -o ashift=12 -d /dev/disk/by-id. Das vermeidet der Fall, daß man in Zukunft nicht zu einer AF-Platte wechseln kann, während es unempfindlich gegen die grundsätzlich >unbekannte Reihenfolge macht, mit der die Festplatten im System erscheinen.

Wo stammt denn dieser Rat her? den kann ich nicht auf der angegebenen Seite finden. Wenn der von woanders oder von dir ist, muss das gekennzeichnet werden - IMHO.

Ok. Da ich selber seit Jahren ZFS verwende (damals war es noch nichtmal beta), und ebenso lange deren Entwickler-Diskussion verfolge, habe ich manche Dinge daraus ergänzt. Den Link auf die Diskussion hatte ich bereits eingefügt. Und mehr Urheberei muß wohl nicht sein.

Was ist denn nun genau Deduplizierung, das solltest Du nach Möglichkeit erkären.

Hmh. Ich schrieb es bereits: Ich WILL nicht ALLES von ZFS hier erklären, denn dann müßte ich 100 Seiten schreiben! Die Kurzfassung für dich: Deduplizierung heißt, daß ZFS Blöcke, die schon mal irgendwo auf der Platte sind, nicht nochmal speichert. Das heißt z.B. identische /home/user-Verzeichnisse, oder wenn verschiedene Benutzer die gleichen Dateien speichern, muß ZFS die nicht mehrfach real vorhalten. Sehr angenehm, wenn man z.B. mehrere virtuelle Maschinen des gleichen OS betreibt, wo naturgemäß viele Dateien identisch sind...

Den Text Warnung/Vorbehalte habe ich noch mal neu fromuliert, weil ich deine Übersetzungen für zu sehr verkürzt halte.

Ich dachte eigentlich, daß mein englisch ganz brauchbar wäre. Aber für mein Deutsch gilt das wohl nicht! 😉 Deine Übersetzungen klingen dermaßen geschmeidig, daß ich sie zu 100% übernommen habe.

Danke dafür! Datakanja