Stabilität/Konsistenz UFS unter FreeBSD9

[minimike]

Hi

Ich denke gerade über eine VM im ESX nach.Sie soll 64 bis 128 MB Ram.und 600 GB Plattenplatz bekommen.
Dienste, SSH, gogoc, radvd und rsnpshot. Also kurz die soll via Tunnelbroker als IPv6 Router dienen. Firewall macht IPFW. Und zusätzlich soll die 2 Server mit Rsnapshot sichern. Damit soll die zwei bestehende Systeme ablösen und noch weniger an Resourcen verbrauchen.
Da ich unter FreeBSD 8 recht übele Erfahrungen mit UFS gemacht habe wollte ich fragen wie es nun mit SU+J unter FreeBSD 9 ausschaut. Kann mann das bedenkenlos verwenden bei beliebig vielen Hardresetts oder wenn die VM mal intern crasht?

 

[Azazyel]

Ich denke gerade über eine VM im ESX nach.Sie soll 64 bis 128 MB Ram.und 600 GB Plattenplatz bekommen.

Gibt es einen bestimmten Grund für die absurd niedrige RAM-Zuteilung?
1 GB RAM (mit ECC) kostet momentan 5 Euro!

Dienste, SSH, gogoc, radvd und rsnpshot. Also kurz die soll via Tunnelbroker als IPv6 Router dienen. Firewall macht IPFW. Und zusätzlich soll die 2 Server mit Rsnapshot sichern. Damit soll die zwei bestehende Systeme ablösen und noch weniger an Resourcen verbrauchen.

Ich werde das Gefühl nicht los, hier wird an der falschen Stelle gespart.

Da ich unter FreeBSD 8 recht übele Erfahrungen mit UFS gemacht habe wollte ich fragen wie es nun mit SU+J unter FreeBSD 9 ausschaut. Kann mann das bedenkenlos verwenden bei beliebig vielen Hardresetts oder wenn die VM mal intern crasht?

ZFS ist unter solchen Umständen wesentlich besser. UFS mit SU+J hat noch derbe Probleme, wie u.a. Yamagi festgestellt hat: PR 163310

Das eigentliche Problem ist aber dein Setup. Wenn du nicht einmal einen halbwegs stabilen Betrieb gewährleisten kannst, läuft irgendetwas gehörig schief.

 

[minimike]

Es läuft momentan nichts schief. Aber ich gehe vom am schlechtesten möglichen Zustand aus. Aufgrund meiner Erfahrung ist immer gut das was derzeit schlecht laufen könnte noch zu potenzieren. Wenn dann mal was schief geht ist man Dankbar das es selbst nach unten noch Reserven gibt.

Und 128 MB Ram halte ich für die paar Sachen gar nicht mal zu wenig. Warum sollte ich dann noch auf ein oder zwei weitere VM's verzichten sofern es dann gar nicht nötig wäre.

 

[Yamagi]

Ob nun SU+J oder nur SU ist eine Glaubensfrage. Ich fahre alle 9.0-Systeme mit SU+J (außer sie haben ZFS) und hatte bisher keine ernsthaften Probleme. Im Labor gelang es mir nicht, nicht hardwareinduzierte Dateisystemkorruption hervorzurufen, in der Praxis habe ich auch noch keine gesehen. Ich würde daher sagen, dass nichts dagegenspricht SU+J einzusetzen. Zudem ändern SU+J den SU-Algoritmus ja nicht, sie fügen lediglich das Journaling der als frei zu markierenden Blöcke ein. Dadruch können beim Neustart diese gezielt geprüft werden, man muss nicht mehr alle im Rahmen eines vollständigen fsck ablaufen.

Es gibt in 9.0 allerdings zwei Probleme, die für 99,8% der Nutzer aber irrelevant sein dürften:
- Wie Azazyel schon sagte, sind die Snapshots in 9.0 im Eimer, wenn SU+J genutzt wird. Da ich derjenige war, der die letzten drei schweren Snapshots-Bugs gefunden hat - der erste war über Jahre unenddeckt, der zweite über sechs Monate und Nummer drei immerhin fünf Monate - schließe ich einfach mal, dass sonst niemand mehr Snapshots auf UFS nutzt. Denn zumindest zwei der drei waren nicht zu übersehen. *schulterzuck* Aber egal. Der aktuelle Stand ist, dass die Snapshots in 9-STABLE prinzipiell gefixt sind, Kirk möchte sie aber vorerst gesperrt lassen, bis einige Dinge am VFS geändert wurden. Einige davon sind schon drin, andere noch nicht. Zumindest gibt's in 9-STABLE halt keinen Crash mehr, stattdessen eine Fehlermeldung, das Snapshots nicht gehen.
- Der Lemming-Syncer existiert in verschiedenen Formen seit mindestens FreeBSD 3 und gehört zu diesen Problemen, die lange konzeptionell schlicht irreparabel waren. Allerdings war auch er praktisch nie ein Problem, denn um den Syncer über die Klippe springen zu lassen, benötigt es schon einer sehr extremen Menge Metadatenoperationen. Er mit SU+J und den einhergehenden Änderungen am Code wurde er behebbar (ohne zu große Risiken eingehen zu müssen), die notwenigen Änderungen sind allerdings erst in 9-STABLE gelandet. Kurz gesagt hat 9-STABLE eine sicher um 100x schnellere Verabreitung der Metadaten, wobei der Effekt umso stärker wird, je mehr Vnodes im Flug sind. Auch werden in 9-STABLE nicht mehr alle Vnodes alle 30 Sekunden gesynct, stattdessen jede Vnode einzeln 30 Sekunden nach ihrer letzten Änderung. Das verteilt Metadaten-Last deutlich besser. Der Effekt kann enorm sein (in einem Test 10 Sekunden statt fat 20 Minuten), aber der normale Anwender wird ihn eher nie spüren, da er mit dem Problem nicht in Berührung kam.

 

[Azazyel]

Es läuft momentan nichts schief. Aber ich gehe vom am schlechtesten möglichen Zustand aus. Aufgrund meiner Erfahrung ist immer gut das was derzeit schlecht laufen könnte noch zu potenzieren. Wenn dann mal was schief geht ist man Dankbar das es selbst nach unten noch Reserven gibt.

Dann bin ich beruhigt; es hat sich so gelesen, als würde die VM sich häufiger "mal so" verabschieden.

Und 128 MB Ram halte ich für die paar Sachen gar nicht mal zu wenig. Warum sollte ich dann noch auf ein oder zwei weitere VM's verzichten sofern es dann gar nicht nötig wäre.

Mit 128 MB RAM wird schon ein portupgrade ohne anderweitige Systemlast interessant. VM sei Dank lässt sich das bei Bedarf aber problemlos erhöhen.

Sobald du die Konfiguration am Laufen hast, würde mich interessieren, ob/inwieweit sich die Performance mit mehr RAM verbessert.

 

[minimike]

Mit 128 MB RAM wird schon ein portupgrade ohne anderweitige Systemlast interessant. VM sei Dank lässt sich das bei Bedarf aber problemlos erhöhen.

Sobald du die Konfiguration am Laufen hast, würde mich interessieren, ob/inwieweit sich die Performance mit mehr RAM verbessert.

compat6x-amd64-6.4.604000.200810_3 A convenience package to install the compat6x libraries
gettext-0.18.1.1    GNU gettext package
gmake-3.82          GNU version of 'make' utility
gogoc-1.2           GogoCLIENT, connect to Freenet6 tunnel
isc-cron-4.1        ISC Cron, former Vixie Cron
libiconv-1.13.1_2   A character set conversion library
lua-5.1.5_4         Small, compilable scripting language providing easy access 
nmap-5.61.t5        Port scanning utility for large networks
p5-CPAN-Meta-2.120921 The distribution metadata for a CPAN dist
p5-CPAN-Meta-Requirements-2.121 A set of version requirements for a CPAN distribution
p5-CPAN-Meta-YAML-0.008 Read and write a subset of YAML for CPAN Meta files
p5-JSON-PP-2.27200_1 A JSON::XS compatible pure-Perl module
p5-Lchown-1.01_1    A perl5 module providing access to lchown(2)
p5-Module-Build-0.4000 Build and install Perl modules
p5-Module-Metadata-1.000009 Perl extension to gather package information from perl modu
p5-Parse-CPAN-Meta-1.44.03 Parse META.yml and other similar CPAN metadata files
p5-Perl-OSType-1.002 Map Perl operating system names to generic types
p5-version-0.99     Perl extension for Version Objects
pcre-8.30_1         Perl Compatible Regular Expressions library
perl-threaded-5.12.4_4 Practical Extraction and Report Language
pkg-config-0.25_1   A utility to retrieve information about installed libraries
popt-1.16           A getopt(3) like library with a number of enhancements, fro
portmaster-3.11     Manage your ports without external databases or languages
rsnapshot-1.3.1     Filesystem snapshot utility based on rsync(1)
rsync-3.0.9         A network file distribution/synchronization utility
sudo-1.8.4_1        Allow others to run commands as root

Das wären alle Installierten Ports. Es fliegen noch vier runter. Ich denke das wäre vernachlässigbar. Mich ärgert derzeit das zwei Maschinen für den Job knapp 768 MB verbraten.

 

[minimike]

Also ich habe nur Angst das sich folgende Situation wiederholt http://www.bsdforen.de/showthread.php?t=27580&highlight=ufs

Und da habe ich den Horror
Der Produktivserver ist abgeraucht und nicht mehr zu fixen. Ich will auf das Backup zugreifen und die VM ist vorher kürzlich aus irgendwelchen Gründen abgestürzt. Das Dateisystem ist seit dem Crash beschädigt und das Backup aus dem Grund nun auch nicht verwertbar.

Das Problem was ich mit UFS hatte, kannte ich unter Linux nur mit EXT2.
Würde mich also SU+J davor bewahren?

 

[Rakor]

Ich versteht bis heute nicht wieso die UFS-snapshots angeblich niemand nutzt. Für mich gibt es noch immer keine bessere Backuplösung (auf UFS-Systemen) wie dump/restore. Die zwischenzeitlich hohe Last zur Erzeugung des snapshots bedrückt mich als Privatanwender nicht wirklich und ich erhalte sehr einfache und robuste Backups.
Außer des Fehlers in SU+J sehe ich auch keinen Grund Backups anders (und damit frickeliger) zu erzeugen. Mein "Lösung" war hierzu übrigens auf das J zu verzichten zu Gunsten der snapshots.

 

[Crest]

ACK. Ich bin direkt bei der ersten Installation mit SU+J über die Snapshotprobleme gestolpert. Yamagi war so freundlich sich darum zu kümmern den Scheiß als PR zu reproduzieren und zusammen zu fassen. Es stellte sich raus, das ein dump -L auf einem SU+J UFS schon reichte.

 

[Yamagi]

Also ich habe nur Angst das sich folgende Situation wiederholt http://www.bsdforen.de/showthread.ph...&highlight=ufs

Die kurze Antwort ist, dass dich SU+J vor soetwas nicht schützt. Für die lange Antwort muss ich ein wenig ausholen. Die Idee hinter SU ist, dass das Dateisystem atomar (also immer, in jedem unteilbar kleinen Augenblick) konsistent ist. Um das zu erreichen, werden Daten und Metadaten voneinander getrennt. Während Daten sofort ausgeschrieben werden, sammelt man die Metadaten im RAM und schreibt ("synct") sie alle 30 Sekunden auf die Platte. Dieses "syncen" läuft so ab, dass das Dateisystem konsistent gehalten wird, entweder eine Änderung geht komplett durch und ist dauerhaft gespeichert oder sie geht nicht durch und ist verloren. Das impliziert, dass bei einem Crash, Stromausfall oder ähnlichen ein konsistenter Zustand gegeben ist und keine weiteren Maßnahmen nötig sind. Nun gibt es aber zwei Probleme:
1. Löschen von Daten kann nicht atomar konsistent erfolgen, da es zwei Operationen sein müssen. a) Gebe die Blöcke frei und b) trage sie in die "Free Space Map" ein. Es kann nun also passieren, dass Blöcke freigegeben aber nicht in die Free Space Map eingetragen sind. Diese Blöcke können nicht neu vergeben werden, sie sind "geleckt". Ein fsck erkennt die fehlenden Einträge und trägt sie nach. Dies kann sogar dann geschehen, wenn fsck im Hintergrund auf einem Snapshot läuft. SU+J führt nun Buch über die zu löschenden Blöcke und ermöglicht es fsck damit gezielt jene Blöcke zu prüfen, die problematisch sein könnten. Statt Stunden dauert der Vorgang nur noch Sekunden.
2. Ist damit alles in Ordnung? Nein! Denn SU verlangen, dass die Hardware korrekt arbeitet. Wenn ihr gesagt wird "Schreibe unter Umgehung aller Caches aus" und ein "Okay" zurückkommt, muss auch wirklich ausgeschrieben worden sein. Leider begann einige Hardware ab ca. 1997 in diesem Punkt zu lügen, sie sagt "Okay", obwohl die Daten noch im Flug sind. Kommt es dann zum Ausfall, ist das Dateisystem inkonsistent, da nicht alles ausgeschrieben wurde... Der Effekt wird umso stärker, je größer die Caches sind und je mehr die Hardware lügt. Es lohnt sich daher bessere Hardware (sogenannte "Serverplatten") zu kaufen und wenn das nicht geht (wie z.B. in virtualisierten Umgebungen) den Write-Cache der Platten abzuschalten.

Daher: Schalte mal den Write-Cache ab und schaue, wie viel Leistung es dich kostet. Bei echten Platten ist der Effekt oft extrem (80% oder mehr Durchsatz-Verlust), in virtualisierten Umgebungen deutlich geringer. Zumindest bleibt das Dateisystem (vorausgesetzt, der Hypervisor cached nicht dennoch munter weiter) hinterher konsistent und solche Totalcrashes, wie du sie erlebt hast, sollten nicht mehr auftreten. Egal ob SU oder SU+J. Wenn die Hardware lügt, kann dir übrigens ZFS auch nicht mehr helfen. Es fliegt lediglich spektakulärer als UFS auseinander.

 

[Rakor]

Es lohnt sich daher bessere Hardware (sogenannte "Serverplatten") zu kaufen und wenn das nicht geht (wie z.B. in virtualisierten Umgebungen) den Write-Cache der Platten abzuschalten.

Ich dachte immer, dass dieser Effekt bei alle Platten auftritt die einen Write-Cache verwenden...? Heißt das, dass eine "bessere" Platte erst das OK liefert wenn die Daten aus dem Cache auf die Platte geschrieben wurden? Dann habe ich doch aber keine Geschwindigkeitsvorteile mehr durch den Cache... Oder sehe ich da nun etwas falsch?

 

[Yamagi]

Ja, tust du Einfach gesagt gibt es zwei ATA oder SCSI-Kommandos:
- "Schreibe" schreibt Daten in den Cache und irgendwann schreibt die Platte sie aus.
- "Schreibe durch" umgeht den Cache und lässt die Platte sofort ausschreiben.
Wenn die Hardware lügt, wird auch "Schreibe durch" durch den Cache geleitet und es wird Erfolg zurückgegeben, obwohl die Daten noch im Cache liegen. Es macht die Platte natürlich schneller, bzw. lässt sie schneller erscheinen, aber riskiert die Sicherheit der Daten. Dazu ist noch zusagen, dass die Metadaten ("Schreibe durch") gegenüber den Nutzdaten ("Schreibe") geradezu verschwindent klein sind.

 

[minimike]

Nun unter Load komme so auf 72 MB Speichervebrauch. Die Tage werde ich noch Sendmail gegen Nullmailer austauschen und den Kernel verschlanken. Mal sehen ob ich dann noch auf 32 MB komme ohne das die Kiste swappt.

Die erste Backupbüchse mit ZFS ist nun in Rente. Das Debian System das den Tunnelrouter spielt übrigens auch.

Ich hatte das mit Linux jahrelang auf einer NSLU2 am Start.

 

[Yamagi]

Den Kernel zu verschlanken wird nicht wahnsinnig viel bringen. So ziemlich genau das, was das Kernelimage kleiner wird... Ein paar Megabyte halt. Aber gut, Kleinvieh macht ja auch Mist. Wenn du es wirklich klein haben möchtest, schaue dir mal Nanobsd an: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/nanobsd/index.html Damit bekommt man das System (ohne Zusatzanwendungen!) so klein gehauen, dass es selbst auf ~256MB Flash-Speicher und 32MB RAM noch halbwegs gut läuft. Noch kleinere Systemimages baut TinyBSD, aber das ist für die meisten Zwecke zu schmal: http://martenvijn.nl/trac/wiki/TinyBSD