falsche Partitionsgröße?

BrainPain

Well-Known Member
Hallo Leute,

ich habe mir einen neuen Rootserver (Hetzner) gegönnt und auf diesen mittels Rescue-System FreeBSD 10.1 installiert.
Laut Hetzner sind in dem System 2 x 3TB verbaut. Diese wollte ich in einem Soft-Raid 1 betreiben. Jedoch habe ich wohl beim Partitionieren mittels bsdlabel -e etwas falsch gemacht.
Code:
#          size     offset    fstype   [fsize bsize bps/cpg]
  a:         4G         16    4.2BSD     4096 16384    75 # /
  b:        16G          *      swap                      # swap
  c:          *          *    unused
  d:        16G          *    4.2BSD                      # /var
  e:         8G          *    4.2BSD                      # /tmp
  f:          *          *    4.2BSD                      # /usr

Laut meinem Verständnis müssten somit doch ca 2,9TB unter usr zur Verfügung stehen. Die Ausgabe von df -h ist jedoch:
Code:
Filesystem          Size    Used   Avail Capacity  Mounted on
/dev/mirror/root    3.9G    483M    3.1G    13%    /
devfs               1.0K    1.0K      0B   100%    /dev
/dev/mirror/var      15G    3.3M     14G     0%    /var
/dev/mirror/tmp     7.7G     24K    7.1G     0%    /tmp
/dev/mirror/usr     680G    290M    626G     0%    /usr

Wie macht man es richtig?
 
Habe es selbst rausgefunden. Scheinbar kann man ab einer bestimmten Plattengröße kein bsdlabel mehr verwenden. Ich habe nun die Partitionen in bsdinstall mit gpt angelegt. Nun werden mir für /usr ca 2.7TB angezeigt. Trotzdem vielen Dank an diejenigen die es sich zumindest durchgelesen haben.
 
bsdlabel ist quasi obsolet.
gpt ist die richtige Wahl.

Noch der Einwand: geht es denn nicht mit ZFS?
Im allgemeinen bin ich kein unbedingter Anhänger von ZFS für jeden Fall und für immer, aber bei allen SW-Raid-Lösungen hat es nach meiner Ansicht die Nase deutlich vorne, ist einfach und komfortabel.
 
bsdlabel / disklabel, MBR-Tabellen und was dort draußen sonst noch so herumkreucht kann maximal 2^32-^ Blöcke oder Bytes... Daher ist wie pit234a sagt inzwischen GPT das Mittel der Wahl, denn es hat praktisch keine Begrenzungen.
 
Naja, der Beitrag ist inzwischen 5 Jahre alt und seitdem ist viel Wasser in die Nordsee geflossen. Aber ich bleibe dabei: Wenn man einfach nur Daten speichern will und die Features von ZFS (Volumenmanagement, Snapshots, Integritätsprüfung, etc.) nicht benötigt, ist UFS die bessere Wahl. Einfach weil es ein erprobtes, sehr robustes und in Sachen Ressourcen genügsames Dateisystem ist. Durch die dedizierten Syncer-Threads für einzelne Mountpoints ab FreeBSD 10.1 hat es auch noch mal einen unerwartet großen Performance-Sprung gemacht, gerade in Fällen wo man auf mehreren SSDs hohe Last anliegen hat. Die beiden Sysctl braucht man übrigens nicht mehr. 'vfs.read_max' steht inzwischen auf 64, zusammen mit der irgendwann mal auf 32 Kilobyte erhöhten Blocksize ist es schon ganz ordentlich. Der Dirhash-Algorithmus wurde irgendwann komplett überarbeitet und konfiguriert sich nun von allein, 'vfs.ufs.dirhash_maxmem' sollte groß genug sein.

ZFS hat als damals noch junges Dateisystem natürlich die größeren Sprünge gemacht. Einmal ist ZFS deutlich schneller geworden. Meine Aussage, dass es gerade auf einzelnen Platten langsamer als UFS ist und nur bei kleinen Dateien Vorteile hat, würde ich heute so nicht mehr machen. UFS und ZFS nehmen sich unter dem Strich in Sachen Performance nichts mehr. ZFS hat zwar noch immer die Nachteile eines Copy on Write Dateisystem, aber sie sind deutlich geringer geworden. Man kann Pools über den Daumen problemlos bis ca. 95% Füllstand fahren, bevor die Dinge eklig werden. Der Preis ist, dass ZFS 3,3% des verfügbaren Speichers immer frei hält, sie also nicht nutzbar sind. Man sollte sich dort auch nicht von ZFS gigantischen Fragmentierungsangaben täuschen lassen, erfahrungsgemäß hat auch ein sehr hoher Fragmentierungsgrad nur geringe Performanceauswirkungen.

Damals war ZFS fehlende Effizienz noch ein großes Thema. In gleichem Maße wie es schneller geworden ist, ist der Bedarf an CPU-Zeit zurückgegangen. Heute kann man ZFS auch auf kleinen CPUs ohne nennenswerten Overhead ausführen. Die meiste CPU-Leistung verbrennt es prinzipbedingt für die optionale Kompression und das Verteilen der Daten auf große RAID-Arrays. Sein Cache (der ARC) integriert nun deutlich besser mit dem Gesamtsystem und ist nicht mehr ganz so hart an die Größe der Pools gebunden. Da sich die verbauten RAM-Mengen zudem vergrößert haben, ist es kein Problem mehr. Beispielsweise ist auf meinem Desktop der ARC auf 6GB begrenzt, aber auch nach 3 Tagen Update nutzt er sie nicht mal halb aus:
Code:
ARC: 2614M Total, 452M MFU, 1222M MRU, 576K Anon, 27M Header, 912M Other
 
Es gibt auch gelegentlich noch immer Hinweise, dass UFS und ZFS nicht gut miteinander können und zumindest Performance-Probleme die Folge des Mischens sind. Für mich ist die Frage immer auch, was kann ich mir leisten und wie gut muss etwas für meine Zwecke sein. Nicht immer ist das, was ich als optimale Version beschrieben sehe auch das, was zu meinen Ideen passt.
Für mich gibt es gute Gründe, mein System auf UFS zu setzen, aber, wo ich Daten lagern möchte und irgendeine Raid-Konstruktion dafür im Sinn habe, da nehme ich ZFS und ich mixe damit diese beiden Dateisysteme. Mein System liegt auch auf einem extra Medium, das ich geklont nochmal verfügbar habe und schnell ersetzen kann. Natürlich könnte das auch auf mehreren Medien redundant realisiert werden (etwa mit ZFS) und damit noch bessere Ausfallsicherheit bieten, aber wie schon erwähnt, kommt es ja auch darauf an, was ich mir leisten kann und ich nutzte lieber die vorhanden SATA-Anschlüsse für die Datenplatten. Auf mein System will ich dann allerdings so wenig wie möglich schreiben, nutze noatime und keine Softupdates und lege alle Logs (die ich im Normalbetrieb sogar abschalte) auf das ZFS. Außerdem lege ich viel in tmpfs. Damit bin ich insgesamt sehr zufrieden, wenn es auch den Designkriterien für saubere und performante ZFS-Systeme nicht genügt und sicher nicht unter 4GB RAM benötigt.
Und ZFS deshalb, weil ich nach einigen Versuchen mit anderen Möglichkeiten davon total begeistert war. Es ist sehr einfach zu verwalten, läuft stabil und gut und hat bei mir auch schon einige Stromausfälle überstanden, wofür es ja eindeutig nicht gebaut ist.
All das kann natürlich für dich kein Tip sein, weil deine Umgebung vollkommen anders aussieht und du andere Anwendungen vor hast und deshalb vollkommen unterschiedlich denken musst. Aber, vielleicht kann es ein wenig ermutigen, denn ZFS spart wirklich viel Arbeit und tut seine Dienste gut.
 
Hmm... Die eigentliche Frage ist ja geklärt und daher denke ich leite ich den Thread nicht noch weiter in die Irre indem ich auch noch ein paar Gedanken von mir dazu gebe.

Die Probleme mit gemischten Systemen "UFS und ZFS" sind meines Wissens nach mittlerweile deutlich entschärft, ich meine in der Manier nicht mehr vorhanden. Ich meine das Problem war im Chaching begründet das sich gegenseitig aufschaukeln konnte. Faktisch hatte man ja aber früher nur wenig andere Wahl. Es gab Zeiten da konnte man noch nicht direkt von ZFS booten und hatte alleine daher schon beide Systeme.

Wenn es denn für die Systempartition etwas Redundanz geben soll aber kein ZFS dann täte es ja auch ein gmirror. Ich verwende es seit Jahren problemlos. Damit hat mein ein UFS und dennoch ein Mirror falls mal was sein sollte.

Leider haben die Softupdates in UFS die Snapshots kaputt gemacht und ich glaube das Problem ist bis heute nicht behoben. Zugegeben, die waren nicht sonderlich performant, aber für mich hat es gereicht und hat ein sauberes Abbild der Platte geschrieben.

Ich finde ZFS auch wirklich ein gutes Dateisystem das mittlerweile ja z.B. auch Standard bei PCBSD ist. Die Features sind durchaus sehr nett. Snapshots sind eine wunderbare Sache, die Konsistenzprüfung ist auch toll. Jedoch, finde ich, ist ZFS auch etwas komplexer als es vielen am Anfang den Anschein macht. Um ZFS wirklich sinnvoll nutzen zu können muss man es etwas verstehen (ZIL, ARC) und auch regelmässig pflegen. Ein UFS kann ich installieren und muss mich dann nicht mehr groß damit befassen. Wenn man was schief geht macht er ein fsck beim nächsten Boot und im besten Fall bekommt man wenig davon mit.
Ein ZFS bietet mehr Möglichkeiten die man dann aber auch bedienen muss. Snapshots zu machen ist eine gute Idee... Aber daran zu denken den Platz wieder frei zu geben sollte man auch. Das ist trivial, das ist mir auch klar, aber ich will damit nur sagen ein ZFS ist nicht "ein anderes Dateisystem drunter und gut ist" sondern beeinflusst auch andere Aspekte. Die interne Konsistenzprüfung ist auch nett, aber man sollte auch regelmässig mal ein scrub drüber laufen lassen.
Ein UFS zieh ich hier raus und steck es im nächsten Rechner wieder rein. Das ZFS muss erst mal sauber importiert werden (idealerweise wurde es vorher auch exportiert).
Kurzum: ZFS braucht mehr Beschäftigung als UFS.
 
Selbst ohne den ganzen "Schnickschnack" wäre ZFS für mich einzig und allein wegen der Checksummen erste Wahl. Ich schleppe seit fast 20 Jahren einen Datenbestand über das mittlerweile 4. oder 5. System herum. Ich habe defekte Controller erlebt, die einfach mal 64KB-Blöcke korrumpieren, weil irgendein SiliconImage-Dreck mit irgendeinem VIA-Chipsatz getrieben hat, was er wollte. Selbst von solchen offensichtlichen Desastern abgesehen ist bit rot real und keine Gruselgeschichte.

Wer Checksummen nicht als des Beste seit geschnitten Brot ansieht und nur als nice to have abtut, wurde noch nicht richtig gebissen. :) Edit: Oder schlimmer: wurde gebissen, hat es aber bis jetzt nicht mal gemerkt.
 
Rakor schrieb:
Die Probleme mit gemischten Systemen "UFS und ZFS" sind meines Wissens nach mittlerweile deutlich entschärft, ich meine in der Manier nicht mehr vorhanden. Ich meine das Problem war im Chaching begründet das sich gegenseitig aufschaukeln konnte.
Jepp, es lag am Caching. Es ist aber seit spätestens FreeBSD 9.1 kein Problem mehr. Das kann ich aus erster Hand bestätigen.

Rakor schrieb:
Leider haben die Softupdates in UFS die Snapshots kaputt gemacht und ich glaube das Problem ist bis heute nicht behoben.
Ja, nein, jein. Kirk McKusick hatte damals einen Fix für das Problem committet. Nur da sich keine Tester fanden und das eigentliche Problem überhaupt erst nach fast 6 Monaten aufgefallen war, traue er sich nicht die Sperre wieder rauszunehmen. Wenn mal Zeit(tm) ist, könnte ich es nochmal umfassender testen.

Nachtrag: Die große Hauptrevision ist r232351, es gab noch mehrere Folgecommits - https://svnweb.freebsd.org/base?view=revision&revision=232351
 
Zurück
Oben