Konkatenierte Partionen (zfs, gvinum, gconcat und co)

Wasp

Insektenspray-Gegner
Hallo Forum,

habe mich den halben Tag (und Nacht) durchs Internet gewühlt. Was ich suche, ist die Möglichkeit Partitionen/Platten ohne(!) striping, also schlicht konkateniert zu einer virtuellen Partition zusammen zu fügen. Sinn dahinter ist es, daß wenn eine Platte/Partition aus dem Array ausfällt, die Daten der anderen Partitionen noch brauchbar sind (sein sollen). Desweiteren wäre es nett, wenn man diese virtuelle Partition nachträglich (quasi dynamisch) erweitern könnte.

Da bei gvinum(8) und gconcat(8) das Dateisystem bei Erweiterung mittels growfs(8) vergrößert werden muß, mit dem ich allerdings z.Z. nicht einmal eine 100 GB große Partition vergrößert bekomme, deren Ende hinter "der" 200 GB grenze liegt, habe ich zunächst mein Glück mit ZFS/zpool versucht, auch wenn mehrere Quellen davon sprechen, daß ZFS nur striping können soll. (Eines vorweg: teste noch mit ZFS 14, aber zumindest bis ZFS 28, seh ich keine Erweiterungen, die ich bräuchte.)

Code:
# mdconfig -a -t swap -s 100m
md0
# mdconfig -a -t swap -s 100m
md1
# mdconfig -a -t swap -s 100m
md2
# zpool create test /dev/md0 /dev/md1
# zpool status
   pool: test
  state: ONLINE
  scrub: none requested
config:

         NAME        STATE     READ WRITE CKSUM
         test        ONLINE       0     0     0
           md0       ONLINE       0     0     0
           md1       ONLINE       0     0     0

errors: No known data errors
Jetzt zwei Testdaten raufgeschrieben, um danach das dritte Gerät hinzuzufügen.
Code:
# vim meinedatei
# echo "Zweite Datei mit Inhalt." > meinezweitedatei
# cat meinedatei
Das ist einen Datei mit Text zum Test.
Es gibt sogar eine zweite Zeile.
# zpool add test /dev/md2
# zpool status
   pool: test
  state: ONLINE
  scrub: none requested
config:

         NAME        STATE     READ WRITE CKSUM
         test        ONLINE       0     0     0
           md0       ONLINE       0     0     0
           md1       ONLINE       0     0     0
           md2       ONLINE       0     0     0

errors: No known data errors
Soweit funktioniert auch alles wie gewünscht, leider läßt sich das gerät nicht wieder entfernen.
Code:
# zpool remove test /dev/md2
cannot remove /dev/md2: only inactive hot spares or cache devices can be removed
Offline (inactive) bringen geht leider auch nicht:
Code:
# zpool offline test /dev/md2
cannot offline /dev/md2: no valid replicas
Dann folgt halt simulierter Ausfall des "mittleren" gerätes.
Code:
# mdconfig -d -u 1 -o force
1# zpool status -v
pool: test
state: UNAVAIL
status: One or more devices are faulted in response to IO failures.
action: Make sure the affected devices are connected, then run 'zpool clear'.
see: http://www.sun.com/msg/ZFS-8000-HC
scrub: none requested
config:

NAME STATE READ WRITE CKSUM
test UNAVAIL 0 0 0 insufficient replicas
md0 ONLINE 0 0 0
md1 REMOVED 0 0 0
md2 ONLINE 0 0 0

config:

         NAME        STATE     READ WRITE CKSUM
         test        UNAVAIL      0     0     0  insufficient replicas
           md0       ONLINE       0     0     0
           md1       REMOVED      0     0     0
           md2       ONLINE       0     0     0


errors: No known data errors
Interessanter Weise sind die Daten trotz angeblichem striping noch vorhanden und lesbar, auch wenn das cat(1) in einem ununterbrechbaren Zustand landet:
Code:
# lg /test/
meinedatei meinezweitedatei
# cat meinedatei
Das ist einen Datei mit Text zum Test.
Es gibt sogar eine zweite Zeile.

^C^C
Das töten von cat(8) auch mittels -9 zeigt leider keine Wirkung. Habe daraufhin versucht mittels zpool scrub test die Daten zu reparieren (=wegschmeissen), aber endet leider auch im uninterruptible state. Gleiche Schicksale ereilt andere Befehle das ZFS betreffend: zpool status -v als auch zpool scrub -s test.

Frage(n):
  • Bekomme ich den zpool, natürlich ohne die Daten von md1, also nur mit md0 und md2 wieder ans Leben?
  • Bekomme ich meinen gewünschten Effekt mit ZFS irgendwie hin?
Falls das mit ZFS/zpool nicht geht:
  • Kann ich die Daten beim Ausfall eines Teils des Volumens bei gvinum oder gconcat retten/behalten?
  • Gibt es noch andere, vorzugsweise Boardmittel neben zpool, gvinum und gconcat die ich noch nicht gefunden habe, mit denen ich mein Effekt erreichen könnte?

Besten Dank im Voraus
Wasp

PS: Das Problem mit growfs(8), habe ich schon mal selbst versucht zu patchen (uint32->uint64), allerdings bisher ohne Erfolg. Ohne die Blöcke bisher ausgerechnet zu haben, so kommt mir die Grenze von 200 GB allerdings etwas weit vorne vor, hätte sie bei 2 TB erwartet -- bis zu 200 GB konnte ich das Dateisystem noch ohne Probleme vergrößern.
 

jmt

Well-Known Member
Deine Beschreibung klingt für mich eher, als suchst Du ein UnionFS. Probier es doch einmal mit fusefs-mhddfs.
 

Yamagi

Possessed With Psi Powers
Teammitglied
Sobald du eine nicht redundante Platte aus dem Pool entfernt, sperrt der Pool augenblicklich beim nächsten Write-Request. Alle IO-Operationen werden damit dauerhaft blockiert, es kommt zu einem absichtlich herbeigeführten Deadlock. Der Grund dafür ist, dass man so verhindern kann, dass die Daten auf den verbleibenden Platten inkonsistent werden und der Pool durch das Wiedereinfügen des fehlenden Mediums noch repariert werden kann. Der einzige (offizielle) Weg den Pool wieder zu entsperren ist ein Reboot mit allen Medien angeschlossen. Man kann allerdings das Verhalten im Fehlerfall per Properties beeinflussen, zu empfehlen ist das jedoch nicht!

Davon einmal abgesehen macht es keinen Unterschied, ob man ein Stripping oder ein Concat Dingens hat. Die Daten verteilen sich immer auf mehrere Platten. Bei einem Concat sind zwar theoretisch die Daten der verbleibenden Platten vorhanden, allerdings können auch Teile der Dateien auf der fehlenden Platte liegen. Außerdem gehen jede Menge Metadaten verloren, was sehr wahrscheinlich die Struktur des Dateisystem irreparabel zerstört.
 

Wasp

Insektenspray-Gegner
Yamagi schrieb:
Die Daten verteilen sich immer auf mehrere Platten. Bei einem Concat sind zwar theoretisch die Daten der verbleibenden Platten vorhanden, allerdings können auch Teile der Dateien auf der fehlenden Platte liegen.
Das ist mir klar und hatte ich auch schon dran gedacht. Jedoch dachte ich, ich muß mir die Chance auf noch intakte Dateien nicht völlig zerstören, indem ich sie von vornherein zerpflücke und auf allen (potentiell mal defekten) geräte Verteile.

Ich habe die defragmentierung von FreeBSD/UFS nie richtig vestanden, aber soviel ich weiß soll das UFS es irgendwie im Hintergrund von alleine machen und gerade das defragmentieren sollte ja nicht nur zum schnelleren Lesen/Auffinden von Daten beitragen, sondern würde auch im Fall der Fälle dafür sorgen, daß möglichst viele Dateien auf der selben (physischen) Partition liegen -- vorausgesetzt das Volumenen ist Konkateniert und nicht "gestreift"... :) oder irre ich mich?
Yamagi schrieb:
Außerdem gehen jede Menge Metadaten verloren, was sehr wahrscheinlich die Struktur des Dateisystem irreparabel zerstört.
Okay, daß wußte ich bisher noch nicht. Gibt es dafür keine Mechanismen, diese wieder herzustellen? fsck und Konsorten zum Beispiel?

jmt schrieb:
Deine Beschreibung klingt für mich eher, als suchst Du ein UnionFS. Probier es doch einmal mit fusefs-mhddfs.
fusefs löst bei mir immer leichte Ticks aus. Es erinnert mich immer an schlecht dokumentierte Software gepaart mit ... schlecht programmierter Software. Aber zumindest was ich gerade von mhddfs gelesen habe, klingt es vom Prinzip echt nach dem, was ich suche, auch wenn es mich etwas vor fuse-xy bangt.

Besten Dank schon einmal für die Antworten
Wasp
 

Yamagi

Possessed With Psi Powers
Teammitglied
fsck und "zfs scrub" sind dazu da, Fehler in den Metadaten zu finden und zu beheben. Sie können allerdings keine fehlenden Metadaten ersetzen. Wie sollten sie auch? Wenn die Information wo der Inhalt welcher Datei liegt und welche Eigenschaften die Datei hatte weg sind, sind sie verloren und können nicht wiederbeschaffen werden. UFS mit seinem statischen Layout ist das noch vergleichsweise nett. Man kann notfalls ein Teil-Dateisystem ablaufen, bis man einen Superblock findet und anhand dessen Informationen die Lage der Metadaten berechnen. Diese dann auslesen und versuchen die Dateien zu rekonstruieren. Allerdings bin ich mir nicht sicher, ob ffs2recov mit solch schwer beschädigten Dateisystemen klar kommt oder man selbst etwas coden müsse. Aber bei völlig dynamischen Dateisystemen wie ZFS oder auch Linux XFS geht das eh nicht mehr, weil die Position der Metadaten nicht vorhersagbar ist. Man muss die oft über die ganze Platte verteilte Datenstruktur komplett durchlaufen, wenn sie irgendwo unterbrochen ist, ist das meist nicht mehr möglich.
 

TCM

Well-Known Member
Was ist denn das für ein Anwendungsfall? Geht's nur mir so oder kommen immer häufiger Leute und an wollen sich auf umständlichste Weisen in den Fuß schießen? Was man heutzutage an "Fragen" sieht, da kann man nur den Kopf schütteln.

Nimm doch einfach einzelne Platte mit einzelnen Partitionen. Wozu die alle zusammenhängen? Einfach nur sinnlos.
 

edlomprul

Well-Known Member
Naja, es kann schon bequemer sein, einfach eine zusammenhängende Riesenpartition zu haben. Er müsste dann evtl. große Dateien nicht händisch splitten.
Ist aber auch wieder ziemlich sinnlos: Selbst wenn die Dateien wie an einer Schnur erst auf einem Medium und dann auf dem anderen gespeichert würden, ergeben sich mehrere Probleme:
Man soll eine Festplatte nicht bis zum Anschlag voll machen (Defragmentierung nur noch schlecht möglich) und die gesplittete Datei ist bei nem Laufwerksausfall ziemlich sicher im Arsch.

Bin auch der Meinung, dass das Vorhaben eher sinnlos ist. Einfach striping ZFS (welches auch die Datenintegrität sicherstellt) und Backup imho.
 

Crest

rm -rf /*
Teammitglied
Du willst ernsthaft Dateien die größer sind als eine moderne Festplatte verarbeiten ohne redundanten Massenspeicher? Bei dem Verhältnis von Bandbreite zu Kapazität eines solchen Gebildes verbringst du mehr Zeit mit Backups als mit sinnvoller Arbeit.
 

TCM

Well-Known Member
Schon die Versuche mit ZFS werfen die Frage auf, auf welchem Niveau und wozu hier überhaupt "gearbeitet" wird. Da wird anscheinend einfach mal ZFS benutzt, ohne den geringsten Schimmer über dessen Funktionsweise. Und wenn ZFS dann zurecht ins Essen kotzt und sogar versucht, den "User" mit allen Mitteln darauf hinzuweisen, dass er grad kompletten Müll fabriziert, wird nicht etwa hinterfragt, ob das überhaupt Sinn ergibt, was man da frickelt. Nee, da wird nach Alternativen gefragt, um den gleichen Mist irgendwie anders hinzukriegen.

Wir werden hier einfach nur hart getrollt. So dumm kann keiner sein.
 
Oben