Geli und Plattenaufteilung

[Wasp]

Hallo Forum,

habe mir gerade (mal wieder) eine neue größere Festplatte als Datenlager zugelegt und bin am überlegen, ob ich die 3 Slices alle in einen geli-container packe oder ob es sinnvoller ist diese in 3 getrennte geli-container zu legen.

Pro für getrennte Container mit jeweils einem Slice:

• Sollte ein Container Probleme habe, lassen sich die anderen ggf, noch entschlüsseln

Pro für einen einzelnen Container mit 3 Slices in einem:

• Slices sollte sich innerhalb des geli-Containers nachträglich vergrößern/verkleinern lassen (oder?)
• Bequemlichkeit -- nur ein Paßwort

Hat dazu jemand Erfahrungen, Empfehlungen oder noch besser empirische Auswertungen von Ausfallraten die nur Teile der Platte involvieren, so daß andere Partitionen noch rettbar sind? Oder ist in 99% der Fälle eh alles kaputt?

Mir selbst fehlt da leider -- oder vielleicht auch zum Glück -- der Erfahrungsschatz, wie etwaige Hard- oder Softwarefehler zu Datenverlust führen können und wie häufig das Eine oder das Andere vorkommt; sprich: die Begrenzung durch Slices den Schaden eingrenzen konnten. Erschwerend kommt im Fall der Fälle ja noch die Verschlüsselung hinzu, welche ich so einschätze, daß Schäden in einem Slice in jedem Fall zum Totalschaden auf dem entsprechenden Slice führt. Doch ist die Frage für mich: würde es -- "Kosten-Nutzen-Faktor" weiter im Blick (s.o.) -- helfen, jedes Slice getrennt zu verschlüsseln.

Besten Dank im Voraus
Wasp

PS: Ja, ich mach alle 30 Sekunden ein Backup nach /dev/null. Aber im Ernst, es sind keine wirklich wichtigen Daten, aber was man halt so hat und doch behalten möchte.

[Crest]

Mit Keyfiles könntest du zwar mehrere GELI Consumer auf dem selben Provider betreiben, aber sinnvoll ist es nicht. GELI geht nicht mal eben kaputt. Performancevorteile sind ebenfalls nicht zu erwarten, weil GELI schon pro Instanz multithreaded arbeitet.

[Wasp]

Erst einaml besten Dank für Deine Antwort.

Zitat von Crest

GELI geht nicht mal eben kaputt.

Ja, davon gehe ich aus, ich bezog das auch eher auf Hardwarefehler -- auch wenn ich etwaige Softwarefehler nicht auschließen wollte und will.

Vielleicht, oder ziemlich sicher, rührt meine frage ja auch aus mangelndem Verständnis. Ich stell mir vor, daß wenn zum Beispiel mehrere Blöcke auf einer unverschlüsselten Festplatte "verschwinden" dann sind nur die einzelnen Dateien betroffen. Wie sieht das da bei einer verschlüsselten Festplatte aus? Ich habe die Befürchtung, daß durch die Verschlüsselung die gesamten Daten eines GELI-Containers (unabhängig von der Zahl der Consumer) betroffen sind.

Damit ergeben sich für mich zwei Fragen:

• seh ich das so richtig?

und selbst wenn nicht:

• gibt es andere "Ereignisse" bei denen es von Vorteil ist getrennte GELI-Container zu haben -- mangelndes Erinnerungsvermögen ans Paßwort mal ausgeschlossen.

[Crest]

Solange nicht gerade die GELI Metadaten betroffen sind wird GELI die einzelnen I/O Fehler durchreichen. D.h. du kannst noch immer die meisten Blöcke lesen.

[Wasp]

Hier mal eine weiterführende Frage in Richtung Umsetzung:

Habe nun vor die Festplatte in 3 bzw. 4 Teile zu teilen.

1. Teil unverschlüsselt,
2. Teil verschlüsselt (teilt sich intern in 2 Teile)
3. Teil anders Verschlüsselt.

Hierbei soll nun der 2. Teil jedoch unter der gleichen Verschlüsselung zwei Partitionen/Slices aus den im Eingangsthema genannten Gründen enthalten (vgl. f. Abb.).

|== (1) ==|==== (2 (--a--|--b--) =====|== (3) ==|

Meine erste Idee war nun drei GPT-Partitionen anzulegen, in dessen zweite Partition (um die es mir jetzt geht) ein GELI-CONTAINER zu legen und in diesen wiederum mit bsdlabel zwei Partionen anzulegen.

Nun wurde ich jedoch darauf hingewesen, daß bsdlabel "deprecated" ist und kam durch einen anderen Forenbeitrag auf die Idee, dann halt einen weitere GPT-Tabelle innerhalb des GELI-Containers anzulegen (GPT -> GELI -> GPT), jedoch ist mir dies nicht möglich:

~# gpart create -sgpt ad12s2.eli
gpart: provider: Device not configured

Im Gegensatz zu einem ältneren bereits vorhandenem (logisch) gleichen Konstrukt, welches mir mittels gpart show auch mit ad6s1.eli gelistet wird, wird mir ad12s2.eli nicht unter gpart show angezeigt. (ad6s1.eli: fdisk -> GELI -> bsdlabel.)

Auf der Lösungssuche stieß ich auf das hier: http://www.freebsd.org/cgi/query-pr.cgi?pr=157721; Essenz: "GPT does not nest." -- okay, aber wie dann? Immerhin wird mir ja die alte Partionierung auch sogar auch richtig von gpart angezeigt.

(Glaube ich habe eh noch die Partionstypen in GPT falsch. ("freebsd-ufs" statt "freebsd", bzw. an der Problemstelle vielleicht was ganz anderes? Die manpage zu gpart schweigt sich auch hierzu aus und ist im ganzen auch sehr besch..eiden.)

~# gpart show ad12
=>             34  5860533101  ad12  GPT  (2.7T)
                  34              4062            - free -  (2.0M)
              4096      10485760     1     freebsd-swap  (5.0G)
      10489856  4800380928     2     freebsd  (2.2T)
  4810870784  1049661440     3     freebsd  (501G)
  5860532224                911            - free -  (456K)

[Azazyel]

Zitat von Wasp

Habe nun vor die Festplatte in 3 bzw. 4 Teile zu teilen.

1. Teil unverschlüsselt,
2. Teil verschlüsselt (teilt sich intern in 2 Teile)
3. Teil anders Verschlüsselt.

Das klingt nach einer Lösung auf der Suche nach einem Problem. Keep it simple stupid.

Die Fehlerquellen, die sich aus obiger Konstruktion ergeben, dürften wesentlich schwerwiegender sein als etwaige defekte Sektoren oder Dateisystem-Bugs.

[Yamagi]

Also: GPT hat durchaus gravierende Vorteile, weshalb ich es jedem ans Herz legen würde. Es kann praktisch unbegrenzt viele Partitionen, ist wesentlich robuster als die alte MBR-Tabelle und vor allem kann es auch Medien größer als 2 Terabyte verwalten. Aber wie du schon korrekt festgestellt hast, kann man GPT nicht ineinander verschachteln. Daher wirst du um BSDlabel oder sogar MBR innerhalb einer GPT-Partition nicht drum herum kommen.

Ist BSDLabel veraltet? Ja! Es ist wie MBR ein endloses Gefrickel. Fragil, überholt, murks. Kurz gesagt ein Hack aus einer anderen Zeit. Aber das heißt nicht, dass man es nicht nutzen kann. BSDlabel hat uns 25 Jahre lang gute Dienste geleistet und tut es heute auch noch. Unterstützt werden wird es sicher noch die nächsten 2000 Jahre, schon allein, da man alte Medien noch lesen möchte. Also mache dir da am besten nicht zu viele Gedanken und nimm es einfach.

Zu den Partitionstypen: "freebsd", "freebsd-ufs" und so weiter sind nur die menschenlesbare Form sehr abstrakter GUIDs. Die meisten Betriebssysteme interessieren sich außerhalb ihres Bootvorgangs nicht für den Partitionstyp, sie schauen nach, welches Dateisystem innerhalb der Partition ist. Aber tun sie es nicht, können sie weitere Informationen entnehmen. Zum Beispiel sagt ihnen "freebsd" einfach, dass dort irgendwas vom FreeBSD drin ist. "freebsd-ufs" hingegen zeigt klar an, dass es sich um ein FreeBSD UFS Dateisystem handelt. Mein Tipp ist, es richtig zu machen. Es hilft auch dem Nutzer, der in 3 Jahren die Platte umpartitionieren darf.

[Wasp]

Zitat von Azazyel

Das klingt nach einer Lösung auf der Suche nach einem Problem.Keep it simple stupid.

Findest Du den Kommentar nicht auch unpassend? Nach meinem derzeitigen Wissensstand ist das die simpelste Lösung für meine Zielsetzung. Würde ich meine Ziele der/einer einfachsten Lösung angleichen, wäre ich wohl noch bei Produkten aus Redmond.

Zitat von Yamagi

Aber das heißt nicht, dass man es nicht nutzen kann.

Ja, habe schließlich zuvor auch jahrelang benutzt und hatte auch keinerlei Probleme damit. Aber wenn ich jetzt schon GPT nehmen, dann wollte ich es gleich richtig machen; aber anscheinend gibt es keine (GPT-)Lösung für mein Problem. Macht mir zugegebenermaßen GPT unsympatisch: "Nesting is not allowed by policy." -- verdammt unsympathisch.

Dann jetzt also doch GPT <- GELI <- BSD-Label.

Danke für Deine ausführliche Antwort Yamagi.

Wo wir gerade bei "richtig machen" sind: das Partitionen auf die Blöcke ausgerichtet werden ist ja klar, aber warum werden die letzten paar Kilobyte hinten weggeschmissen? Nicht das ich ernsthaft 456 KB lange hinterher weinen würde, aber gibt es dazu einen plausiblen Grund? Meiner Meinung nach könnten die doch einfach hinten mit ran oder hat es Performanzvorteile diese abzuschneiden? Beginnen sollten sie ja auf dem richtigen Block.

[Azazyel]

Zitat von Wasp

Findest Du den Kommentar nicht auch unpassend? Nach meinem derzeitigen Wissensstand ist das die simpelste Lösung für meine Zielsetzung.

Es ist wohl die simpelste Lösung für das angedachte Partitionierungsschema.

Für die Zielsetzung einer möglichst zuverlässigen Speicherung von Daten auf einer Festplatte baust du meiner Meinung nach sehr viel fehlerträchtige Komplexität ein.
Deiner Beschreibung kann ich nicht entnehmen, warum du mehr als einen Container und ein Slice einsetzen möchtest (plus evtl. Platz für das Betriebssystem selbst), geschweige denn unterschiedliche Verschlüsselungen.

Die Zeiten notorisch unzuverlässiger Dateisysteme, die bei jedem Stromausfall unrettbar inkonsistent wurden, sind vorbei.

Zitat von Wasp

Würde ich meine Ziele der/einer einfachsten Lösung angleichen, wäre ich wohl noch bei Produkten aus Redmond.

Du setzt also FreeBSD ein, weil es komplizierter ist als Windows?

Eines der Prinzipien von Unix ist doch die Rule of Simplicity, die ich in der Lösung vermisse.

Zitat von Wasp

Macht mir zugegebenermaßen GPT unsympatisch: "Nesting is not allowed by policy." -- verdammt unsympathisch.

Vielleicht wollten die Entwickler genau solche Komplexitäten vermeiden und verhindern, dass sich ein Anwender damit in den Fuß schießt.



Bezüglich der Ausfallwahrscheinlichkeiten von Festplatten sei noch auf eine Google-Studie verwiesen (Failure Trends in a Large Disk Drive Population); in der Zusammenfassung weisen die Autoren aber darauf hin, dass sich für einzelne Festplatten schwerlich eine Vorhersage treffen lässt:

Zitat von Failure Trends in a Large Disk Drive Population

Despite those strong correlations, we find that
failure prediction models based on SMART parameters
alone are likely to be severely limited in their prediction
accuracy, given that a large fraction of our failed drives
have shown no SMART error signals whatsoever. This
result suggests that SMART models are more useful in
predicting trends for large aggregate populations than for
individual components.

[Yamagi]

Das SMART Murks ist, weiß sicher jeder, der mal Probleme mit Festplatten hatte. SMART ist wie Memtest86 oder Kamillentee bei Erkältung. Man kann sich einreden, dass es bei der Problemlösung hilft, aber realistisch gesehen ist es nur schwarze Magie. Ich hatte schon Platten, die nur noch Klickten und SMART sagte "passed". Alles Tip Top. Ich hatte Platten, die laut SMART "failed" waren und noch Jahre liefen... Davon einmal abgesehen, führen wir in der Firma eine seit 1982 laufende Liste in der jede ausgelieferte Festplatte mit ihrem Schicksal verzeichnet ist. Und daraus kann man zwei simple Erkenntnisse ziehen:

- Alle Hersteller sind gleich Murks. Sie haben alle mal bessere und schlechtere Serien, aber im Schnitt gleicht es sich aus. Die einzige Ausnahme ist Connor, aber die sind auch vom Markt aussortiert worden. Allerdings ist seit etwa 2007 ein deutlicher Verfall der Zuverlässigkeit zu sehen, was hauptsächlich an den diversen Firmwaremacken der letzten Jahre liegt. Nach dem Ende der Garantie steigen die Ausfallraten stark an.

- Man kann sehr gut erkennen, welche Serie gut und welche schlecht ist. Leider erst knappe 3 Jahre nach dem Erscheinen, wenn es niemandem mehr hilft.

So, nun aber zum Thema. Das man GPT nicht verschachteln kann liegt einfach darin begründet, dass die Spezifikation es nicht hergibt. Die GPT liegt im zweiten und im letzten Sektor des Mediums und nirgendwo anders. Die Partitionen werden als Offsets zum Beginn des Mediums angegeben... Ja, man könnte darum herumfrickeln, aber wieso sollte man? Verschachtelte Partitionen sind ein Szenario, was man nur sehr selten finden wird.

[Wasp]

Sieht hier jemand einen Fehler:

=>             34  5860533101  ad12  GPT  (2.7T)
                  34              4062             - free -  (2.0M)
              4096      10485760         1  freebsd-swap  (5.0G)
      10489856  4800380928         2  freebsd  (2.2T)
  4810870784  1049662351         3  freebsd  (501G)

=>        0  600047615  ad12s2.eli  BSD  (2.2T)
             0  600047615                    - free -  (2.2T)

~# gpart add -t freebsd-ufs -s 1989g -l downloads ad12s2.eli
gpart: autofill: No space left on device

Habe auf Grund dieses Fehlers bereits die gesamte Festplatte noch mal komplett gelöscht und neu partitioniert, aber kein unterschied. Der Witz an der Sache: ich habs zuvor an einem md0 probiert und da gings.

Nachtrag:
Habs jetzt wieder wie früher auch mit bsdlabel gemacht der hat "Platz" gefunden. Aber ganz geheuer ist mir GPT nun noch weniger.

[Yamagi]

Wie ich oben schrieb, kann ein bsdlabel durch die Nutzung von 32 Bit Zeigern nur Partitionen mit einer maximalen Länge von 2^32 Byte (ca. 2TB) adressieren. Oder anders gesagt: Speicherplatz nach den 2TB ist nicht mehr nutzbar, deine Partition beginnt aber bei 2,2TB. Ergo ist dort kein Speicherplatz für das bsdlabel vorhanden, gpart sagt es dir.

Alles weitere liegt in der Funktionsweise von gpart(8) und bsdlabel(8) begründet. gpart arbeitet korrekt vom Start des Medium aus, verweigert daher den Dienst. bsdlabel kann aber nicht zwischen Medium und Partition unterscheiden, hält ad12s2.eli für eine komplette Platte und schreibt ein Label, welches mit Index 0 beginnt. Das ist aber Murks und hat gute Chancen eher früher als später zu explodieren. Es hat schon seinen Grund, dass sehr viel Arbeit in gpart geflossen ist...

[Wasp]

Das würde dann aber heißen, daß ich die Festplatte nicht so partitionieren kann, wie ich möchte -- nur weil GPT meint keine verschachtelten GPTs zu wollen.

Nur der Richtigkeit halber: die 2,2 TB Partition beginnt bei 5 GB endet allerdings außerhalb der 2 TB Grenze. Da ich schon Daten aufspiele scheint es (noch) zu gehen. Frage ist jetzt, ob ich jetzt nur 1995 GB habe (abzüglich der ersten 5 vom Swap), ich 2000 GB habe, weil er den GELI-Container als eigene Festplatte versteht und einfach bei 0 anfängt zu Adresserien. oder ob er irgendwann anfängt Müll zu machen; z.B. in die Swap-Partition schreibt.

Welche Möglichkeiten habe noch mit denen ich den GELI-Container Partitionieren kann um so zwei getrennte UFS-Dateisysteme zu erhalten?

[Wasp]

Bin der Sache noch mal nachgegangen, da es zumindest scheinbar nicht so bleiben konnte wie ich es jetzt hatte; außerdem lasse ich mir nur ungerne von Programmen und erst Recht nicht von (sinnlosen?) "Spezifikation" vorschreiben, wie ich meine Platte einteile. Aber zum Thema...

Zitat von Yamagi

bsdlabel [kann] durch die Nutzung von 32 Bit Zeigern nur Partitionen mit einer maximalen Länge von 2^32 Byte (ca. 2TB) [sig*] adressieren. Oder anders gesagt: Speicherplatz nach den 2TB ist nicht mehr nutzbar, deine Partition beginnt aber bei 2,2TB. Ergo ist dort kein Speicherplatz für das bsdlabel vorhanden, gpart sagt es dir.

Habe wie gesagt noch mal recherchiert und muß Dich in ein paar Punkten korrigieren. Damit aber andere auch was davon haben, hier etwas ausführlicher:
Nach dem FreeBSD-Handbuch Kapitel 19.3 adressiert bsdlabel Sektoren (und nicht Byte). Diese sind bzw. waren üblicherweise 512 Byte groß, woraus die Grenze von 2 TB (2^32 Sektoren * 512 Byte) resultiert. Wie auch unter http://lists.freebsd.org/pipermail/f...ry/009973.html angemerkt wird, können mit einer größeren Sektorgröße auch größere Slices erzielt werden. Bei einer Sektorgröße von (in meinem Fall) 4096 Byte also 16 TB.

Interessant finde ich desweiteren, daß man -- ausgehend von 512 Byte-Sektoren -- selbst mit fdisk theoretisch noch 4 TB fehlerfrei partitionieren könnte; allerdings ist man hierbei mit der Einteilung der Festplatte nicht ganz frei, da die letzte Partition spätestens nach 2 TB beginnen muß. Da auch hier wieder Sektoren und nicht Byte adressiert werden, wäre bei der Wahl einer größeren Sektorgröße, somit auch die Partitionierung von größeren Festplatten möglich. Allerdings wurde unter oben genannter Mailinglist festgestellt, daß die Sektorgröße,zumindest bei FreeBSD 7.3, fest in fdisk ein-programmiert und nicht änderbar ist.

Wenn ich das also alles richtig verstanden habe, sollten meine beiden Slices über die 2,2 TB in der zweiten Partition von GPT durch die Sektorgröße von 4k problemlos funktionieren.

Korrekturen und (konstruktive) Anmerkungen sind weiterhin willkommen
Wasp

sig*: 2^32 Byte sind 4 GB (und nicht 2 TB).

[Yamagi]

Ja, du hast natürlich recht, dass es Blöcke statt Byte sind. Das hätte ich auch gern selbst bemerken können, denn eigentlich(tm) sieht man es schon an der Dimension der Zahlen... Und daraus folgt dann auch, dass eine größere Blocksize eine längere Partition ermöglicht. Dennoch habe ich so meine Zweifel, dass es dir etwas nützt. Denn die Kernelseite von gpart(8) liest die Blocksize aus GEOM (sys/geom/part/g_part_bsd.c:217), GEOM wiederum erhält sie beim Erstellen des Providers durch ada(4) (sys/cam/ata/ata_da.c:1072). Und da meines Wissens alle auf dem Markt erhältlichen Laufwerke eine logische Blocksize von 512 Byte nutzen, ist für GEOM die Blocksize nun einmal auf 512 Byte festgelegt und damit die maximale Länge einer bsdlabel-Partition auf 2TB.

Daraus folgen zwei Möglichkeiten:
1. Das bsdlabel irgendwie so umbiegen (z.b. mit gnop(8)-Magie), dass es eine Blockgröße von 4K sieht.
2. Die Kernelseite vor gpart-bsdlabel-Implementation so umschreiben, dass es die Stripesize (die physische Blöckgröße) nutzt. Das Problem dabei ist, dass nach wie vor alle(?) 4K-Platten und auch SSD lügen und eine Stripesize von 512 Byte vorgeben. Der Kernel hat zwar eine Quirk-Liste (sys/cam/ata/ata_da.c:159ff), um die korrekte Stripesize zu raten, sie muss deine Festplatte aber greifen.

So, ich hoffe, dass wir uns nun einig sind.