ACHTUNG! Journals Softupdates werden heute commitet!

Yamagi

Yamagi

Possessed With Psi Powers
Teammitglied
Guten Morgen :)
Jeff Roberson wird heute im Laufe des Tages seine "Journaled Softupdates" in -CURRENT einfügen. Dies ist ein massiver Eingriff in das UFS-Dateisystem, der Größe seit sicher 10 Jahren. Wer die Journaled Softupdates nicht nutzen wird, sollte keine Auswirkungen spüren. Nach Monaten des exzessiven Testens sollte es auch keine kritischen Fehler mehr geben. Dennoch, wer -CURRENT auf produktiven Systemen nutzt (was man nicht sollte) ist vielleicht dennoch gut beraten, einige Tage mit Aktualisierungen auszusetzen.

Jeff schreibt:
Code: 
  Hi Folks,                                                                     
                                                                                
  You may have seen my other Soft-updates journaling (SUJ) announcements. If    
  not, it is a journaling system that works cooperatively with soft-updates to  
  eliminate the full background filesystem check after an unclean shutdown.     
  SUJ may be enabled with tunefs -j enable and disabled with tunefs -j disable  
  on an unmounted filesystem.  It is backwards compatible with soft-updates     
  with no journal.                                                              
                                                                                
  I'm going to do another round of tests and buildworld this afternoon to       
  verify the diff and then I'm committing to head.  This is a very large        
  feature and fundamentally changes softupdates.  Although it has been          
  extensively tested by many there may be unforseen problems.  If you run into  
  an issue that you think may be suj please email me directly as well as        
  posting on current as I sometimes miss list email and this will ensure the    
  quickest response.                                                            
                                                                                
  Thanks,                                                                       
  Jeff

Was Journaled Softupdates sind und wo ihre Vorteile liegen, habe ich einmal hier hier erklärt: http://www.bsdforen.de/showpost.php?p=206418&postcount=1 Zusammen mit kommenden Änderungen am Dateisystem-Syncer und weiteren Umbauten am VFS bringt dies UFS2 zurück in die Spitzenklasse "klassischer" Dateisysteme. :)
 
Der inzwischen auch in Stable verfügbare geom Scheduler dürfte auch einiges dazu beitragen, auf jeden Fall spannende Entwicklungen :-)
 
Woher kommen eigentlich die ganzen Journaling Bemühungen? Soft-Updates haben mich das letzte mal im 5-stable Zweig im Stich gelassen. Und die Folgen waren nicht weiter fatal. Seit dem haben meine Dateisysteme wirklich schlimme Dinge unbeschadet überstanden.
 
Will Backman hatte im Februar Jeff Roberson bei BSDTalk "zu Besuch". Nettes halbstündiges Interview, bei dem es vorwiegend um SUJ ging: Hier als mp3 und als ogg.
 
Halt, halt. Diese Journaled Softupdated ändern nichts am bisherigen Softupdate-Mechanismus. All ihre Vorteile bleiben erhalten, ihr Funktionsweise gleich. Das Journal sorgt lediglich dafür, dass noch fälschlich als belegt markierte Blöcke ohne fsck freigegeben werden können. Sprich, du kannst nach dem Crash oder Stromausfall gleich weitermachen, musst nicht erst das fsck im Vorder- oder Hintergrund laufen lassen. Es ist also kein echtes Journaling, man führt lediglich Buch über freigegeben Blöcke. Versagt das Journal, ist es nicht weiter schlimm. Softupdates halten das Dateisystem atomar konsistent, einfach fsck laufen lassen, fälschlich als belegt markierter Speicher wird wieder freigegeben und läuft wieder. Wichtig sind Journaled Softupdates, da ein fsck-Lauf auf mehreren Terabyte großen Medien bei vielen Dateien auf ihnen bestenfalls eklig ist und bis zu vielen Stunden dauern kann, schlimmstenfalls unmöglich, da es etliche Gigabytes RAM benötigt. Schon auf mittelgroßen RAID-Arrays von 15TB ist UFS daher im Moment mehr oder weniger hart an der Grenze der Unbenutzbarkeit. Journaled Softupdates lösen dies. Sie sind übrigens optional, wer sie nicht explizit aktiviert, bleibt von ihnen verschont. :)
 
Hmm, ich wundere mich seit langem warum man das Dateisystem nicht in Pakete von ein paar GB aufteilt, die jedes für sich dann CLEAN markiert werden. So wären nach einem Crash wahrscheinlich nur wenige Pakete Dirty.
 
Kamikaze schrieb:
Hmm, ich wundere mich seit langem warum man das Dateisystem nicht in Pakete von ein paar GB aufteilt, die jedes für sich dann CLEAN markiert werden. So wären nach einem Crash wahrscheinlich nur wenige Pakete Dirty.
Zum Vergrößern anklicken....

Ich denke da fügst du eine menge Komplexität hinzu die das Filesystem stark verlangsamen dürfte, denn so wie ich mir das vorstellen würde schlägst du da vor ein Dateisystem aufzusetzen, alle 4GB o.ä. wieder ein neues Dateisystem zu setzen und diese entweder als ein FS oder für größere Dateien als "Blöcke" zu verwenden. Das stelle ich mir höllisch kompliziert vor.
 
Ja, wäre es. Simpel gesagt ist das Problem hinter den Softupdates folgendes: Ein Block ist als belegt markiert, soll nun freigegeben werden. In einem ersten Schritt wird er aus der ihn referenzierenden Inode entfernt, er ist nun wieder frei. In einem Schritt wird er in die "Free Space Map" eingetragen, erst jetzt sieht das Dateisystem selbst ihn als frei und kann ihn neu vergeben. Dies sind zwei Operationen, die in zwei atomaren Schritten ausgeführt werden müssen. Was nun passieren kann ist, dass die Inode den Block freigibt, dass System aber crasht, bevor die Free Space Map aktualisiert werden kann. Der eigentliche freie Block ist dann nicht nutzbar, fsck muss ihn erst in die Free Space map eintragen. Dies ist der einzige Grund, weshalb fsck mit Softupdates zwar nicht notwendig ist, aber dennoch gemacht werden sollte. Daher kann es auch im Hintergrund ausgeführt werden, die Free Space Map kann jeder Zeit bearbeitet werden. Mehrere Maps, Blöcke oder sonstwas bringt schon daher nichts, da fsck ja nicht weiß, welche Blöcke wo im Dateisystem fälschlicherweise als belegt markiert sind. Er müsste wieder alle Blöcke und alle Inodes ablaufen, außer du führst Buch über deine Operationen. Und dann kannst du auch gleich wieder Jeffs Journal nehmen. :)
 
Was mach ich den grundsätzlich falsch?

Letzte Woche wurde SU+J für FreeBSD8/AMD64 current getestet und mksnap_ffs(8) wird im Zustand 'jwait' (top(1)) geblockt und nur ein Reboot scheint Abhilfe zu schaffen. Der Backingstore des Snapshots wird also nicht vollständig angelegt und das Filesystem kann dann nicht mehr über das Journal sondern muss mit klassischem fsck repariert werden. Und speziell in so einem Fall muss manuell interveniert werden, da bei einem gescheiterten Journal-replay ("fsck_ufs: Journal file sequence mismatch 306 != 305") nicht anschließend automatisch ein "fsck -y" (FSCK_Y_ENABLE='YES') ausgeführt wird. Das ist derzeit für ferne Systeme unpraktisch.

(Und growfs(8) könnte auch entsprechend gepflegt werden, weil das derzeit das Journal zerstört. *schmoll* )

Hab' aber noch zu nix recherchiert, weil ich faul wie ein Hund bin. *ich wollt', ich könnt' sowas coden, niederknie*
 
Zuletzt bearbeitet:
Moment, vielleicht dumme Frage. Du sprichst von einem "Backingstore", meinst du zufällig "gjournal"? Wenn nicht, ignoriere mich einfach. :)
 
Hi Yamagi, :)

ne, es wird kein gjournal-Layer benutzt, sondern wirklich nur ein SU+J Filesystem auf das dann versucht wird, ein Snapshot zu errichten:

%newfs -U -O2 /dev/xyz
%tunefs -j enable /suj
%mount /suj
%mksnap_ffs /suj/mysnap
#Kommando bleibt dann "hängen".

/suj/mysnap ist dann der Backingstore

Wird Journaling abgeschaltet, dann geht mksnap_ffs wie sonst üblich durch und erstellt den Backingstore.
 
Zuletzt bearbeitet:
"Heute" wurde aufgrund eines kurzfristig gefundenen Bugs zu "am Wochenende", hier sind sie aber nun:
Code: 
  Date: Sat, 24 Apr 2010 09:05:36                                               
  From: Jeff Roberson <jeff@FreeBSD.org>                                        
  To: src-committers@freebsd.org, svn-src-all@freebsd.org,                      
      svn-src-head@freebsd.org                                                  
  Subject: svn commit: r207141 - in head: lib/libufs sbin/dumpfs sbin/fsck_ffs  
        sbin/fsdb sbin/tunefs sys/kern sys/sys sys/ufs/ffs      sys/ufs/ufs     
      usr.sbin/makefs/ffs                                                       
                                                                                
  Author: jeff                                                                  
  Date: Sat Apr 24 07:05:35 2010                                                
  New Revision: 207141                                                          
  URL: http://svn.freebsd.org/changeset/base/207141                             
                                                                                
  Log:                                                                          
     - Merge soft-updates journaling from projects/suj/head into head.  This    
       brings in support for an optional intent log which eliminates the need   
       for background fsck on unclean shutdown.                                 
                                                                                
    Sponsored by:   iXsystems, Yahoo!, and Juniper.                             
    With help from: McKusick and Peter Holm
 
Die Frage lässt sich ganz einfach beantworten:
- In 9.0 ist SU+J Standard, sprich BSDInstall schaltet sie automatisch ein. Es gibt derzeit keine bekannten Bugs, der bisher letzte (mal wieder Ärger mit Snapshots) wurde kurz nach der BETA3 behoben.
- gjournal war seinerzeit ein schöner Hack, hat aber bis heute einige Macken. Die zeigen sich im normalen Betrieb eher nicht, sind aber auch kaum lösbar. Außerdem ist gjournal tendentiel langsamer als SU+J und das Journal ist um einiges größer.
Also so gesehen ja. gjournal ist nur noch dann sinnvoll, wenn man ein vorhandenes Setup nicht verändern möchte. Eine neue Installation damit würde ich nicht mehr machen.

Ach, ja. Zum nachträglichen Aktivieren von SU+J:
Code: 
tunefs -j enable /dev/partition
fsck_ffs /dev/partition
Das fsck ist wichtig, damit das Dateisystem wirklich sauber ist. Anschließend taucht im Hauptverzeichnis des Dateisystems das Journal als versteckte Datei (Punkt am Anfang) auf. Anstelle eines ganzen "fsck" reicht dann ein "fsck -p", was das Journal zurückspielt. Die rc-Scripte machen das siet jeher vor dem Mount der Dateisysteme. Weiterhin ist wie bei normalen Softupdates ein fsck / Rückspielen des Journals NICHT notwendig, damit das Dateisystem konsistent ist.

Da das Softupdates-Journal kein Journal im eigentlichen Sinne ist (der Name verwirrt in meinen Augen ein wenig), ist es nur wenige Kilobyte groß und hat so gut wie keinen messbaren Overhead gegenüber normalen Softupdates. Die Zeit für das Rückspielen ist gering, maximal einige Sekunden. Dennoch. Wenn man nur sehr kleine Dateisysteme oder schnelle Medien hat, kann man auch auf das Journal verzichten. Meine SSD hier benötigt für ein echtes fsck keine 30 Sekunden, da ist der Zeitgewinn also vernachlässigbar...
 
Dumme Frage. Wenn ich ein FS neu anlege, wie aktiviere ich die Journals? Muss ich da auch über tunefs gehen? Die manpage für newfs (9.0-current) gibt ja nur den -J Parameter für gjournal an.
 
Das geht mit "-j" (kleines j). Frage mich nicht, warum die Manpage es nicht hat...

EDIT: Man sollte vor dem Schreiben neu laden.
 
Hehe, ok. Danke euch beiden... Aber immerhin bin ich beruhigt, dass ich nicht zu blöd bin (und es wirklich nicht in der manpage steht).
 
Bei mir ist es in der newfs Manpage meiner FreeBSD 9-stable Installation von vor ein paar Tagen (nach BETA3). Die Optionen -J und -j stehen allerdings nicht untereinander. Es werden erst Großbuchstaben beschrieben.
 
OK, danke... :) Bei Beta3 habe ich es in den Manpages nicht gefunden und online steht nur die 9.0 -current Manpage, und da ist es auch nich drin :)

Aber mal ganz blöd... impliziert -j das -U oder muss ich beide angeben? :D

Fragen kann der Kerl stellen... ;)
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben