Am Samstag 23 Februar 2008 schrieb Markus Schulz: > > > Das Dateisystem selbst hingegen bleibt eigentlich immer in Ordnung. > > > Es zerschiesst mir nur jedesmal die meisten Inhalte von .mozilla > > > und die Inhalte von .gaim, manchmal auch die von /var/log. > > > > Das ist aber eine Design-Entscheidung der XFS-Leute, das Daten, die > > korrupt sind, nicht einfach so roh belassen (könnten Leckagen aus > > anderen Dateien sein), sondern eben mit Null überschrieben werden. > > Nichtmal das, es sind Inodes die keine assoziierten Disk-Blocks > besitzen (Data-flush hatte noch nicht stattgefunden) und daher als 0 > ausgelesen werden. > Wenn man bei ext3 data-ordered oder data-writeback als Journaling > Option benutzt (ist ordered nicht auch default?) muss man im Grunde mit > ähnlichen Problemen rechnen. Nur der data-Journal Mode ist dagegen > sicher, schreibt dafür aber alles doppelt, da kann ich im Grunde dann > auch -osync beim Mounten verwenden. Eine Lösung hierfür wäre u.a. ein wanderndes Journal wie in Reiser 4. Reiser 4 legt über zu schreibende Daten einfach on the tly ein Journal , wohl durch entsprechende Markierung, und entfernt diese Markierungen wieder, sobald die Daten geschrieben sind. Dadurch muss nichts doppelt geschrieben werden. Es gab da auch noch andere Ansätze, damit umzugehen, das weiß ich aber grad im Moment auch nicht mehr auswendig, daher verweise ich speziell zu dieser Problematik auch nochmal auf meinen Linux-Magazin-Artikel. Journaling-Dateisysteme unter Linux Beschränktes Schreiben von Martin Steigerwald Erschienen im Linux-Magazin Sonderheft 2006/04 http://www.linux-magazin.de/heft_abo/sonderheft/2006/04/beschraenktes_schreiben?category=0 -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Attachment:
signature.asc
Description: This is a digitally signed message part.