Relativ hoher Datenverlust durch soft updates normal?

F

Florian88

Well-Known Member
Hallo,

ich habe mich viele Jahre nicht getraut soft updates zu verwenden. Letzte Woche habe ich dann mal einen Versuch gewagt und soft updates und journaling aktiviert.

Mir war von Anfang an klar, dass durch den Einsatz von soft updates Schreibvorgaenge verzoegert werden und im Falle eines Stromausfalls bestimmte Dateien weg sein koennen. Allerdings hat mich ueberrascht wie viele das sind:

Vorgestern habe ich vergessen mein Laptop an den Strom zu haengen und der Akku war irgendwann leer und das Geraet ging einfach aus. (Ja ich weiss, ein automatischer Shutdown koennte das verhindern, aber darum soll es jetzt nicht gehen). Ich habe zu diesem Zeitpunkt nicht mit dem Geraet gearbeitet. Es waren also lediglich einige Programme geoeffnet (Thunderbird, Chrome, ...) aber es fanden nicht viele Schreibzugriffe statt.

Nachdem ich das Laptop einschaltete funktionierte das Booten wunderbar und ich musste nicht auf fsck warten, so wie ich es bisher gewohnt war.

Doch dann stellte ich auf Anhieb fest, dass folgende Dateien weg sind und vermutlich noch weitere, die ich bis jetzt nicht bemerkt habe:

- Thunderbird-Profil unvollstaendig.
- Chrome-Profil unvollstaendig
- Pidgin-Profil unvollstaendig.
- Bash-History weg.

Ich frage mich, ob dieser Datenverlust ungewoehnlich hoch ist oder ob das normal ist, beim Einsatz von soft updates.

Ausserdem wuerde ich es praktisch finden, zu wissen welche Dateien beim fsck geloescht wurden. Gibt es eine Moeglichkeit, das Journal einzusehen?


Code: 
# SSD:/
Jan 18 20:30:04  kernel: Starting file system checks:                                                                      
Jan 18 20:30:04  kernel: ** SU+J Recovering /dev/ad8s1a                                                                    
Jan 18 20:30:04  kernel: ** Reading 33554432 byte journal from inode 11.                                                   
Jan 18 20:30:04  kernel: ** Building recovery table.                                                                       
Jan 18 20:30:04  kernel: ** Resolving unreferenced inode list.                                                             
Jan 18 20:30:04  kernel: ** Processing journal entries.                                                                    
Jan 18 20:30:04  kernel: ** 37 journal records in 6144 bytes for 19.27% utilization                                        
Jan 18 20:30:04  kernel: ** Freed 5 inodes (1 dirs) 2 blocks, and 8 frags.                                                
Jan 18 20:30:04  kernel:                                                                                                  
Jan 18 20:30:04  kernel: ***** FILE SYSTEM MARKED CLEAN *****        
# SATA:/home                                                     
Jan 18 20:30:04  kernel: ** SU+J Recovering /dev/ada0s1d.eli                                                              
Jan 18 20:30:04  kernel: ** Reading 33554432 byte journal from inode 4.                                                   Jan 18 20:30:04  kernel: ** Building recovery table.                                                                      
Jan 18 20:30:04  kernel: ** Resolving unreferenced inode list.                                                            
Jan 18 20:30:04  kernel: ** Processing journal entries.                                                                   
Jan 18 20:30:04  kernel: ** 146 journal records in 102400 bytes for 4.56% utilization                                     
Jan 18 20:30:04  kernel: ** Freed 25 inodes (18 dirs) 10 blocks, and 2 frags.                                             Jan 18 20:30:04  kernel:                                                                                                  
Jan 18 20:30:04  kernel: ***** FILE SYSTEM MARKED CLEAN *****
 
Das ist nicht die Schuld von Softupdates (ob mit oder ohne Journaling ist in diesem Fall egal, da das Journaling ausschließlich die Atomizität von Löschoperationen sicherstellt), stattdessen deiner Hardware. Softupdates verlangen, dass die Hardware die Wahrheit sagt, also ein explizites Durchschreiben aller Daten aus den Caches (ein Sync) nur dann mit "Fertig" antwortet, wenn es auch geschehen ist. Nur hat fast alle bezahlbare Hardware das Problem, dass dies nach wie vor nicht gegeben ist, gerade die berüchtigten Writecaches unterlaufen dies Prinzip. Die Folge ist: Anstatt einer rein atomaren Ausführung der Operationen, kommt es zu einer teilweisen Ausführung, die häufigsten Folgen sind leere Dateien (alte Datei dereferenziert, neue Datei ohne Blöcke referenziert) oder verschwundene Dateien (alte Datei dereferenziert, neue Datei referenziert).
Klassische Journaling-Dateisysteme sind davon übrigens auch betroffen, dort meist in Form unvollständiger Journals oder nicht mehr sauber anwendbarer Journals durch Abweichung der Metadaten im Dateisystem. Das ist unter anderem einer der Gründe, dass Linux Ext-Familie alle 120(?) Tage ein fsck erzwingt und man auch unter Windows bei NTFS sich ab und an ein chkdsk gönnen sollte. Praktisch jeder, der komplexere Journaling-Dateisysteme wie XFS nutzt, hat dort nach harten Crashes auch schon Datenverlust gesehen.

Es gibt nur 4 suboptimale Lösungen:
1. Lebe damit. Das machen die meisten Personen.
2. Schalte den Writecache ab, gerade bei S-ATA wird es dadurch aber EXTREM langsam.
3. Investiere in entsprechend zuverlässige Hardware, die allerdings sehr teuer ist.
4. Setze auf ein COW-Dateisystem wie ZFS, was prinzipbedingt wesentlich robuster gegen Cache-Probleme ist. Eine vollständige Immunität ist aber auch dort nicht gegeben.
 
Ich finde das schon ziemlich ungewöhnlich. Bei mir tauchen immer nur Dateien, die zum Schreiben geöffnet waren in lost+found auf. PID-Files und irgendwelches Zeug aus dem Browser-Cache.

Und selbst wenn es die Maschine während dem Schreiben wegreißt, ist eben nach dem fsck noch die alte Version der Datei da.

Allerdings hat bei einem gewöhnlichen Absturz die Festplatte ja noch den Saft den Cache zurückzuschreiben.

Aber auch wenn mir der Strom ausgeht, hatte ich bisher noch keine Probleme dieser Art. Nicht mehr seit FreeBSD-5.

Ich würde auf jeden Fall mal die lost+found Ordner mit file durchsehen, normalerweise findet man die vermissten Dateien wieder.
 
Erstmal Danke fuer die Antworten. Also damit leben moechte ich ehrlichgesagt nicht, habe meine Profile jetzt wieder zurechtgefrickelt, sodass ich arbeiten kann. Das moechte ich nicht nochmal machen. Falls ich das Problem nicht geloest bekomme, werde ich eher softupdates wieder abschalten. Ging ja all die Jahre auch ohne.

2. Schalte den Writecache ab, gerade bei S-ATA wird es dadurch aber EXTREM langsam.
Zum Vergrößern anklicken....
Sehe ich das richtig, dass das die Variable kern.cam.ada.write_cache ist? Ich werde das mal ausprobieren, die Geschwindigkeit vergleichen und auch mal den Stecker ziehen und sehen was passiert.

Hat jemand ein Beispiel, fuer eine vernuenftige Festplatte, bei der das mit dem Writecache ordentliche funktioniert?

Ich wuerde ungerne ZFS auf einem Notebook einsetzen. Ich mag ZFS zwar sehr gerne und habe echt gute Erfahrungen auf Servern gemacht, aber ich finde es einfach zu maechtig und zu ressourcenhungrig fuer ein Notebook.

Im Ordner Lost+Found hab ich uebrigens gar nichts gefunden, was von dem besagten Absturtz stammte.

Bei der Platte handelt es sich um eine 500 GB Hitachi Travelstar (HTS725050A9A364) mit 16MB Cache - Jemand Erfahrung damit?

Kann ich nach einem Absturtz via Journal rausfinden, welche Dateien kaputt/weg sind? Dann waere es ja recht einfach, diese aus dem Backup wiederherzustellen.
 
Ich habe gerade die drei sysctl-Variablen
kern.cam.ada.write_cache
kern.cam.ada.0.write_cache
kern.cam.ada.1.write_cache
auf 0 und auf 1 gesetzt und jeweils chromium gebaut um festzustellen, welchen Einfluss der Write-Cache auf das Bauen von Ports hat.
Ich konnte hierbei keine nennenswerten Performance-Unterschiede feststellen.

Dann ist mir aufgefallen, dass unabhaengig von den sysctl-Optionen camcontrol stets write cache enable anzeigt. Ich habe auch reboots durchgefuehrt, um sicher zu sein, dass die Optionen uebernommen werden. Trotzdem aendert sich nichts.

Hat jemand eine Idee, was die Ursache hierfuer sein koennte?
 
Florian88: Das bauen von Ports ist lesen von geringen Datenmengen gefolgt von viel Rechenaufwand und anschließendem schreiben der Ergebnisse. Mit der Weile ist das ganze für die meisten Ports auf SMP Systemen auch parallel möglich. Somit ist das nicht Disk I/O bound. Merken wirst du den unterschied z.B. beim entpacken eines Tarballs mit vielen kleinen Dateien.
 
Ach Yamagi, was wuerd ich nur ohne dich machen. Danke.
Hatte sie natuerlich nicht in der loader.conf gesetzt, sondern in der sysctl.conf. Jetzt funktionierts aber.

Hier der Performancevergleich
/usr/ports/www/chromium# make build
WC enable: ca. 34 Minuten
WC disable: ca. 34 Minuten

/usr/ports/www/chromium# make clean
WC enable: ca. 5 Sekunden
WC disable: ca. 10 Sekunden

@Crest: Danke fuer den Hinweis. Das hab ich mir so halb gedacht. Dennoch ist die Performance beim Ports bauen mit das Wichtigste, worauf es mir ankommt. Deshalb wollt ich es mal ausprobieren. Aber man sieht ja wirklich kaum einen Unterschied. Ich koennte also durchaus mit deaktiviertem Write-Cache leben.

Mein Rechner ist vorhin uebrigens, unmittelbar nachdem ich einen reboot machen wollte, eingefroren. Es gab keinerlei Fehlermeldungen. Er hing, noch bevor der X-Server beendet war. Nach einem Kaltstart fehlten wieder die Chrome- und die Pidgin-Einstellungen. Write-Cache war aktiviert. Der Rechner ist ca. 6 Monate alt und hat sich unter FreeBSD bisher noch nie aufgehaengt. Er lief von Anfang an unter FreeBSD Current/9.0. Ich werde das Problem erstmal im Auge behalten, vielleicht ist es ja auch ein Hardware-Bug. Ansonsten sind Softupdates und Trim die einzigen Sachen, die ich konfigurationstechnisch veraendert habe in der letzten Zeit.

Ich habe jetzt den Rechner mal einfach ausgeschaltet (Stecker gezogen) waehrend der Write-Cache abgeschaltet war. Chrome und Pidgin haben danach wieder nicht funktioniert, weil die Preferences-Files weg waren. Mir ist das mit den Softupdates definitiv zu unsicher und ich werde es wieder abschalten. Da warte ich lieber beim Booten in Zukunft wieder 2 Minuten auf fsck, anstatt 15 Minuten irgendwelche Dateien aus Backups zu rekonstruieren.

Aber Danke erstmal, fuer eure Tipps.
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben