Logical Volume Manager für FreeBSD?

foxit

foxit

Well-Known Member
Hallo,

Ich habe hier ein Testsystem, bei welchem die Partitionierung nicht optimal ist. Ich würde gerne (zum Test) ada0p4 vergrössern. Gibt es dazu eine einfache Möglichkeit so wie mit "lvresize" unter Linux?

Gefunden habe ich nicht wirklich etwas schlaues. "gconcat" und "gvinum" aber das ist nicht das Richtige in meinen Augen. Gibt es noch etwas anderes unter FreeBSD?

Danke

Code: 
=>       34  134217661    ada0  GPT  (64G)
         34          6          - free -  (3.0k)
         40        128  ada0p1  p1-boot  (64k)
        168   16777216  ada0p2  p2-root  (8.0G)
   16777384   10485760  ada0p3  p3-var  (5.0G)
   27263144   10485760  ada0p4  p4-usr  (5.0G)
   37748904   10485760  ada0p5  p5-tmp  (5.0G)
   48234664   52428800  ada0p6  p6-zfs  (25G)
  100663464    4194304  ada0p7  p7-swap  (2.0G)
  104857768   29359927          - free -  (14G)
 
GVinum ist die Portierung des alten FreeBSD 4.x Vinum Volume Managers auf GEOM. Es wird von fast niemandem benutzt und hatte zu mindestens in FreeBSD 5.x und 6.x noch viele Probleme. Ich habe keine Ahnung ob es mit der Zeit (wieder) benutzbar geworden ist. Die sauberste Lösung wäre es mit dump/restore die Daten zu sichern und wieder herzustellen. Was mich wundert ist wieso du diverse Partitionen und eine ZFS Partition hast. UFS und ZFS mögen sich nicht gerne. Sie streiten sich ständig ums RAM für ihre jeweiligen Caches. Solltest du also eh ZFS benutzen bietet es sich an nurnoch ZFS zu verwenden. Während dump nur auf UFS Dateisystemen funktioniert ist restore auch auf anderen Dateisystemen einsetzbar. Du kannst also deinen Dump in ZFS entpacken.

Mein Vorschlag wäre: Dampfe das ganze auf 3 GPT Partitionen ein (boot, zfs, swap). Mit ZFS brauchst du dich auch nicht mehr weiter um die Partitionierung kümmern. Solltest du per Dataset Quotas und Reservations in ZFS nutzen wollen ist das natürlich möglich.
 
Ja, gvinum ist benutzbar. Aber so komplex, dass man es nicht nutzen möchte. Die Gefahr von Nutzerfehlern ist viel zu hoch. Daher höre auf Crest und werde glücklich. :)
 
Yamagi schrieb:
Ja, gvinum ist benutzbar. Aber so komplex, dass man es nicht nutzen möchte. Die Gefahr von Nutzerfehlern ist viel zu hoch.
Zum Vergrößern anklicken....

Nutzerfehler? Dieses Wort gibt es in meinem Wortschatz nicht ;)

OK fassen wir zusammen:
- Ein vergleichbares System wie "lvm" gibt es so unter FreeBSD nicht.

Warum dort UFS konfiguriert ist schnell erzählt: TRIM. TRIM Support wurde glaube ich letzter Jahr im Oktober so so "commited" aber ist noch nicht in 9.1 RELEASE. Auch hier im Forum habe ich schon gelesen, dass UFS und ZFS heute keine Probleme miteinander haben sollten. Darum meine Idee mit UFS und ZFS.

Das ZFS Slice ist vorhanden, weil ich dort einen L2ARC Cache für einen ZPOOL erstellen wollte.

Bleibt mir einfach ZFS ohne TRIM zu nutzen und zu hoffen, dass meine SSD nicht zu anfällig ist. Leider ist es ein älteres Model wohl aber mit TRIM Unterstützung. Gut ich werde sicher nicht den ganzen Platz auf dieser SSD benötigen und so auch dem TRIM etwas entgegenstellen. Dann wird es wohl auf ZFS hinauslaufen...
 
Hier gibt's auch keine Probleme mit ZFS und UFS im Parallelbetrieb. Allerdings haben wir auch vfs.zfs.arc_max begrenzt, da die Maschinen auch noch was anderesals den ZFS Cache im Speicher halten sollen ;)
 
Zuletzt bearbeitet:
hallo

lass einfach etwas freien platz auf der ssd ( sprich nicht partitionieren etc ) dann hast du dein trim.
der ssd controller besorgt das dann .

hinzukommt das die meisten neueren ssds kein trim mehr benoetigen.

holger
 
@makenoob
Nur aus Interesse: Was für ein Limit hast du eingestellt?

@all
Danke für eure Hinweise und Meinungen
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben