UFS2-Dateisystem live clonen mit "Soft Updates Journaling"

rMarkus

Chuck The Plant
Hallo,

seit langer Zeit wollte ich ein FreeBSD auf eine andere Platte clonen mit der altbekannten Methode dump/restore:
Code:
cd /zielmnt
dump -a0 -L -C32 -b64 -f - / | restore -rf -

Dabei tauch aber das Problem auf, dass ab FreeBSD 9 das "Soft Updates Journaling" bei der Installation eingeschaltet ist, was auch bei dem dump von FreeBSD 12.0 noch immer nicht unterstützt wird:
Code:
mksnap_ffs: Cannot create snapshot //.snap/dump_snapshot: /: Snapshots are not yet supported when running with journaled soft updates: Operation not supported

Wenn ich das Snapshotting bei dump abschalte (weglassen von -L), dann gibt es aber folgende Warnung:
Code:
  DUMP: WARNING: should use -L when dumping live read-write filesystems!
Da dump unterhalb der Dateiebene scheinbar operiert, besteht dann die Gefahr von korrupten Dateien.

Probleme:
- Hierbei handelt es sich um das Root-Filesystem, daher kann ich es nicht aushaengen oder ro schalten
- Das Abschalten von "Soft Updates Journaling" mit tunefs ist aus mehreren Gründen keine Option
- bei der Verwendung von tar ist nicht wie bei Linux moeglich, denn das bricht bei "special sockets" ab und vor allem muesste man nach meinen Informationen auch noch spezielle Dateirechte mit /etc/mtree/* nachbauen, was etwas eklig ist
Code:
tar cf - --one-file-system --exclude=/bhyve / | tar xfp -

Wie kopiere ich das Filesystem dennoch?
 
Bei BSD ist es normal kein Problem das / im Betrieb auf ro zu setzen. Je nachdem was du auf dem System machst und wie es Partitioniert ist kann das natürlich blöd werden, aber FreeBSD an sich ist es egal. Du kannst sogar ohne Reboot das System ro machen, Journaling deaktivieren, rw setzen, dump benutzen, dann das / wieder ro, Journal an, wieder rw.
 
Eine Alternative, die ich immer mehr schätze, ist rsync
dito.
also, ich hatte das eigentlich immer benutzt und immer ein schlechtes Gefühl dabei gehabt, weil es nicht einen "Snapshot" macht, sondern eben live arbeitet und da kann es dann schon zu Ungereimtheiten bei einigen Dateien kommen. Davon war ich weitgehend verschont geblieben.
Heute mache ich das alles mit ZFS, was dir aber absolut nichts nutzt. Will sagen: ich habe schon lange keine Erfahrung mehr mit rsync bei einem Live laufenden System gemacht. Einen Test ist es aber allemal Wert!
 
Das beste was du da machen kannst ist von journaled softupdates auf softupdates (ohne journaling) umzustellen. Journaled softupdates machen nur für multi TB Dateisysteme wirklich sinn. Bei dem Verhältnis von IOPS und Bandbreite zu Kapazität einer SSD bringt es kaum etwas, aber hat ein paar Nachteile. Auf die Gefahr hin etwas FUD zu verbeiten: der +J Teil an SU+J ist der am wenigsten getestete Code in UFS. FreeBSD 9 hat Snapshots mit SU+J erlaubt, aber es hat zuverlässig direkt in ne Panic geführt, weil der Autor schon weiter gezogen war und die Datenabhängigkeiten in UFS mit SU+J echt unübersichtlich sind wurde der Bug nie gefixed sondern bloß der Fall unerreichbar gemacht indem Snapshots für UFS mit SU+J deaktiviert wurden. Damit ist es nicht möglich UFS Snapshots für einen korrekten Dump zu verwenden solange SU+J aktiviert ist. Für die meisten Systeme auf denen UFS noch Sinn macht ist es meiner Meinung nach besser aufs Journaling zu verzichten als auf Snapshots. Nen Background fsck tut weder auf nem kleinen Embedded System noch ner kleinen VM wirklich weh.
 
Ich war damals die gepeinigte Seele, die das Problem im Zusammenspiel zwischen Journal Softupdates und Snapshots analysiert hat. Von mir kam auch der Vorschlag als Zwischenlösung Snapshots zu sperren, wenn Journaled Softupdates eingeschaltet sind. Das Problem ist, das Softupdates, ihr Journaling und Snapshots alle 3 für sich genommen schon recht komplex sind. Kommen sie zusammen, wird es schnell ein großer Clusterfuck. Da das Interesse an Journaled Softupdates schon kurz nach ihrer Einführung mit FreeBSD 9.0 durch das Aufkommen von ZFS schnell sank und andere Dinge als wichtiger erachtet wurden, hat Kirk McKusick diesen einen Fall - Snapshots auf Journaled Softupdates - nie behoben. Vor einiger Zeit meinte er, dass es wahrscheinlich auch nicht passiert wird, da der Aufwand sich im Bereich von Mannstunden im Wert von mehreren tausend Dollar bewegt und es jemand bezahlen müsste. Nicht, da er geldgierig ist, da gäbe es sicher bessere Möglichkeiten an Geld zu kommen. Sondern, da er irgendwovon leben muss und er die Stunden, die er FreeBSD kostenlos zur Verfügung stellen kann, an anderen Stellen für besser angelegt sieht.

Wie @Crest schon sagt, sind Journaled Softupdates auch gar nicht mal so wichtig. Vorausgesetzt die Hardware lügt nicht, kann man sich den fsck-Lauf nach einem Crash auch komplett sparen. Softupdates selbst garantieren ja Konsistenz, sie können nur nicht sicherstellen, dass alle freigegebenen Frags auch tatsächlich in der Free Space Map als frei markiert wurden. Sprich man verliert halt etwas freien Speicher, was sich aber meist im sehr überschaubaren Bereich bewegt.
 
Das klingt alles etwas übel bei UFS.
Da ich ein absoluter Feind von ZFS bin aus meinen Solaris-Tagen und das System nur ein PC-Engines APU2 ist und seinen Speicher für bhyve braucht und ich keinen an ZFS abgeben kann, ist ZFS keine Option.

Ihr habt mich aber überzeugt, dass ich Soft Updates Journaling besser abschalten sollte.

Bei mir ist das übrigens von dem FreeBSD-Installer gekommen, daher wäre es vielleicht dort auch eine Idee, dass man das nicht per Default so formatiert.
 
Habt ihr eine schnelle Befehlsfolge, wie ich das SU+J auf der root-Partition abschalten kann.

Reboot ohne Consolenzugang wäre einfacher als das Readonly-Schalten des Dateisystems.
 
hunderttausend Jahre her und nun nichts mehr zum Testen: tunefs sollte das machen.
Da gibt es eine Option, alles anzeigen zu lassen, was derzeit ist und dann kann man die jeweiligen Settings gezielt ändern.
Nicht alle lassen sich aber zur Laufzeit ändern, manche brauchen einen Neustart.
Ich erinnerte und fand dann diesen Thread, der vielleicht hilfreich sein mag:
https://www.bsdforen.de/threads/dateisystem-ufs-tunen.33476/
 
So mein vorheriger Post war unterwegs am Handy, jetzt hab ich etwas mehr Zeit:

mount -fr / sollte / RO mounten, das geht auch über eine ssh Verbindung. Die Dienste vom Base-System werden davon nicht gestört und laufen normal weiter.

tunefs -j / sollte das journaling dekativieren.

Danach wieder mit mount -w / das / RW mounten. Vor einigen Monaten wollte ich auch das Journaling loswerden und bin auf 2 Servern so verfahren :)

LG
 
Für das Protokoll, hier die exakten Befehle, wie man das SU+J loswird:
Code:
# Alle Dienste stoppen
mount -fur /
tunefs -j disable /
shutdown -r now
 
Zurück
Oben