• Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr

UFS auf grossen Festplatten

rMarkus

Chuck The Plant
Themenstarter #1
Hallo,

nach vielen Jahren möchte ich das FreeBSD 7.4 durch 10.0 ersetzen.

Da ich mit ZFS unter Solaris/SPARC sehr schlechte Erfahrungen gemacht habe und da ZFS durch die geänderte Politik von Oracle als tot betrachtet werden kann, will ich auf UFS wieder setzen.

Welche Dinge sollte man bei einer 6 TiB-Datenpartition mit UFS beachten?
  • GPT-Partition sollte gesetzt sein, habe ich schon bei FreeBSD 7.4
  • Softupdates ist auch gesetzt
  • Journaling?
  • andere neue Features?

Danke
 

Yamagi

Possessed With Psi Powers
Mitarbeiter
#3
ZFS ist nicht tot. Es gibt nun 2 ZFS:
- Oracle-ZFS, wo niemand so genau weiß ob und wie Oracle daran noch arbeitet.
- OpenZFS, was das gemeinsame Projekt von FreeBSD, Illumos und ZFS on Linux ist. Wir von diversen Firmen unterstützt [1].
OpenZFS hat Oracle-ZFS inzwischen praktisch abgehängt. Es hat diverse Bugfixes, die Oracle nicht besitzt. Es hat eine ganze Menge neuer Features bekommen. Und es wird sehr aktiv entwickelt, allein 46 Commits auf der FreeBSD-Seite des Projekts diesen Monat. Ich glaube nicht, dass ZFS uns wieder verlassen wird. Im Gegenteil, ich schätze, dass OpenZFS eher noch das Fahrt gewinnen wird.

----

Zu UFS: UFS skaliert auch auf sehr großen Medien von etlichen Terrabyte gut. Das größte Dateisystem, was ich mal gesehen habe, war etwa 80TB groß. Wenn man sehr große Verzeichnisse hat, sollte man eventuell das Sysctl "vfs.ufs.dirhash_maxmem" deutlich erhöhen damit er mehr cachen kann. Ab voraussichtlich FreeBSD 10.1 (ca. im Sommer oder Herbst) wird UFS außerdem endlich Syncer-Threads pro Mountpoint unterstützen, d.h. Last auf einem Mountpoint sollte dann nicht mehr alle anderen total blockieren. Softupdates sollte man in jedem Fall setzen. Journaling ist so eine Sache. Entgegen aller Gerüchte funktioniert es gut und sauber, solange man nicht lügende Hardware hat. Das kann man wirklich nicht groß genug schreiben. Daher es im Zweifel lieber ausgeschaltet lassen. Kommt also das klassische fsck ins Spiel, sicher der große Schwachpunkt von UFS. Für Dateisysteme, die ab FreeBSD 9.2 erstellt wurden, ist es ca. 30% schneller als auf älteren Dateisystemen. Viel RAM (den man heute allerdings meist hat), benötigt es allerdings noch immer. Für Labels sind UFS-Label (mit "newfs -L $name" oder "tunefs -L $name) zu empfehlen, die dann in den /dev/ufs/$name auftauchen.

----

1: http://open-zfs.org/wiki/Companies
 

rMarkus

Chuck The Plant
Themenstarter #4
Danke für die Antwort Yamagi.

  • Was ist mit "lügender Hardware" gemeint? Sind damit Plattensysteme gemeint, die ein ACK geben, bevor es wirklich stromausfallfest geschrieben wurde? In meinem Fall ist das ein 3Ware 9750 mit BBU und Storsave Policy auf Balanced.
  • Ist das RAM-Fressen auf UFS oder ZFS bezogen? Ich kenne das eigentlich nur von ZFS, denn da kann man selbst bei 128 GB RAM mit entsprechendem IO Probleme bekommen, d.h. man hat immer zu wenig RAM bei ZFS.
 

Yamagi

Possessed With Psi Powers
Mitarbeiter
#5
- Genau. Platten und / oder Controller, die ACK zurückgeben, während die Daten noch in irgendwelchen Caches liegen und nicht ausgeschrieben wurden.
- Das RAM-Fressen ist auf das fsck von UFS bezogen.Grob über den Daumen benötigt das fsck 1GB RAM für 1TB Speicherplatz (egal ob leer oder belegt) im Dateisystem.
 

worldi

wirrköpfiger Philosoph
#6
OpenZFS, was das gemeinsame Projekt von FreeBSD, Illumos und ZFS on Linux ist.
Man sollte vielleicht noch erwähnen, dass sich da nicht etwa irgendwelche pickeligen Kellerkinder zusammengefunden haben, die da jetzt wild rumfrickeln. Im Gegenteil, da wirken Leute wie Matt Ahrens ("co-founded the ZFS project at Sun") und George Wilson ("senior member of the ZFS kernel development team at Sun") mit.
 

Crest

rm -rf /*
Mitarbeiter
#7
Also UFS verwendet soft-updates statt metadata journaling und kein data journaling. Manche Dateisysteme verwenden data und metadata journaling. Diese Dateisysteme verhalten sich anders für Anwendungen, die beschissen mit ihren Dateien umgehen und kein fsync() verwenden sondern sich auf Eigenheiten von z.B. ext3 verlassen. Diese Anwendungen können dann wunderbar explodieren, wenn sie mit einem anderen Dateisystem konfrontiert werden.

Die soft-updates des UFS sind genau an der Grenze dessen was Festplatten behaupten zu können. Sie verlassen sich darauf das ein write der als auf stable memory gemeldet wird auch wirklich auf stable memory ist. Billige Platten an normalen Controllern sehen das nicht so eng. Besonders Laptopplatten lassen sich oft beim Lügen erwischen. Das Ergebnis ist ein beschädigtes UFS, das ein fsck braucht. Nicht lustig, aber meistens kein Weltuntergang.

Mit guten Platten an nem ordentlichen HW RAID Controller mit BBU wirst du keines dieser Probleme haben. Der Controller bietet einen zuverlässigen write back Cache. Damit kannst du guten Gewissens UFS mit 6TB verwenden, wenn du es willst.

Problematisch an UFS ist das es nach einem Stromausfall oder einer Panic ein background fsck braucht. Dieses braucht trotz aller Optimierungen bei 6TB auf wenigen Platten mehrere Stunden. In dieser Zeit wird fsck langsam immer mehr RAM fressen (so 500MiB bis 1GiB pro 1TiB) und relativ viel IOPS belegen.

Die Lösung dafür ist ab FreeBSD 9.0 journaled soft-updates. Hierbei wird ein kleines Journal geführt in dem nur Allokationen vorgemerkt werden. Mit diesem Journal kann fsck in wenigen Sekunden potentielle Speicherlecks beheben, die soft-updates als einzigen Fehler zulassen. Der Nachteil an den journaled soft-update ist, dass sie sich nicht zeitgleich mit UFS Snapshots verwenden lassen. Damit verliert man die Möglichkeit Backups von r/w gemounteten UFS Dateisystemen per dump -L anzufertigen.

Kommen wir zu ZFS. Damit ZFS seine Selbstheilung durchführen kann musst du ihm die Platten als JBOD durch reichen. Über den write Cache des Controller freut sich ZFS genauso wie jedes andere Dateisystem solange der Controller nen Cache flush auf den Devices als einen in seinen write Cache übersetzt und nicht dumm weiterreicht an die Platten. Bei ZFS ist man meistens besser damit bedient statt eines HW RAID Controllers für das Geld SAS HBA und zwei kleine SSDs zu kaufen.

ZFS benötigt deutlich mehr RAM als UFS, aber damit erkauft man sich vieles.
  • Checksums über Daten und Metadaten gegen Bitrot
  • Snapshots und Clones
  • Speicherverwaltung in Pools statt Dateisystemen
  • Replikation mittels Snapshots
  • ...
Fazit: ZFS macht das Leben des Admins bequemer und ruhiger.
 

rMarkus

Chuck The Plant
Themenstarter #8
Gerade setze ich das um.

Das Thema ZFS lasse ich jetzt mal aussen vor, ich hatte einfach zu schlechte Erfahrungen mit Solaris und ZFS.

Wenn ich eure Vorschläge mit Softupdates und dem journaled Soft-Update folge, dann muesste das Anlegen des Dateisystems so lauten:
Code:
newfs -U -j /dev/da1p1


Insgesamt mit GPT-Partition und Label sieht das dann so aus:
Code:
# gpt-Partitionstabelle anlegen:
gpart create -s gpt da1

# mit voller Groesse Partition darin anlegen
gpart add -t efi da1


# Filesystem erstellen
newfs -U -j /dev/da1p1
# -U Enable soft updates on the new file system.
# -j Enable soft updates journaling
# -J waere die alte Variante:  Enable journaling on the new file system via gjournal


# Label anlegen fuer Platte
tunefs -L home /dev/da1p1


# in fstab mit Label eintragen
vi /etc/fstab

#anhaengen
--
/dev/ufs/home  /home  ufs  rw  2  2
--

mkdir /home
mount /home
 

bsd4me

Well-Known Member
#9
Hallo,

ich verwende ZFS auf "meinen" Solaris 10/11 Servern seit Jahren - und nun auch unter FreeBSD... bisher gab es keine Zwischenfälle. Kaputte Platten wurden schon zigfach ersetzt und das ZFS hat immer funktioniert... :-)

Achja, Einmal gab es eine lustige Begebenheit und zwar nach einem Plattenwechsel:

pool: rpool
state: ONLINE
scan: resilvered 12.0G in 307445734561825859h23m with 0 errors on Tue Jan 10 09:58:50 2012

Tja, das wären dann 35096545041304 Jahre um die Platten zu "resilvern" - hihi

Gruss, Norbert
 

rMarkus

Chuck The Plant
Themenstarter #10
Das System habe ich jetzt sporadisch im Betrieb und nach einem Recover von rund 800 GB (via Bacula) hatte ich das System zerlegt und spaeter wieder in der Konfiguration in Betrieb genommen.

Dann geschah folgendes beim Booten:

dmesg-Meldung nach dem Booten:
Code:
tws0: ERROR: (0x04: 0x005F): Cache synchronization failed; some data lost
Danach habe ich manuell die Daten-Platte geprueft und fehler gefunden:
Code:
###  manueller fsck mit Journal:
    USE JOURNAL? [yn] y
    ** SU+J Recovering /dev/ufs/home
    ** Reading 33554432 byte journal from inode 4.
    RECOVER? [yn] y
    ** Building recovery table.
    ** Resolving unreferenced inode list.
    ** Processing journal entries.


###  manueller fsck ohne Journal (erneut!! auf selber Platte):
    FREE BLK COUNT(S) WRONG IN SUPERBLK
    SALVAGE? [yn] y
    SUMMARY INFORMATION BAD
    SALVAGE? [yn] y
    BLK(S) MISSING IN BIT MAPS
    SALVAGE? [yn]
Bin mir noch nicht sicher, ob mich die Treiberqualitaet vom 3Ware 9750 (im Gegensatz zu denen vom 9650) erschrecken soll, ob das System zu schnell abschaltete (32 GB RAM) oder das UFS mit der Konfiguration nicht gut ist.
Beim Recover ist auch das Dateisystem vollgelaufen und habe dann nebenbei was weggeloescht, kann das auch die Ursache sein?

Nachher habe ich das Problem mit stress und Recover versucht zu reproduzieren und des gelang mir nicht.
(Volllaufen von Dateisystem und Hardware-Zerlegen hatte ich nicht versucht).


Wie ist eure Meinung dazu?