60 tage disc check

60 tage disc check (22 Beiträge, 907 Mal gelesen)

Du bist nicht angemeldet. [ Login/Registrieren ]

Hallo,

ich besitze Linux in der Version 9.3!
Linux führt bei mir regelmäßig (nach 60 tagen) einen "Disk-Check" durch...! Nun ist meine Frage:
Wie schalte ich diesen ab?

ich bedanke mich wieder an jeden helfenden in diesem Forum und freue mich über jede antwort!

mit freundlichen grüßen

Dave

10.01.2006, 15:11 Uhr - Editiert von -"Dave"-, alte Version: hier

*hust* es gibt kein linux 9.3 *hust*

such mal nach dem begriff cronjob + howto

kann sein das es nicht die richtige version ist

Eigentlich gehört das Linux jemand anderen und selbst der weis es nicht genau ^^

cronjob + howto hab danach mal gesucht! Weis aber nicht genau auf was ich da achten soll (Absoluter anfänger)!
Kannst du mir einen direkt-link oder eine genaue erklärung geben?!

vielen vielen Dank für deine Antwort

Dave

http://www.rootforum.de/forum/viewtopic.php?t=16846&postdays=0&postorder=asc&start=0

das scheint mir ausführlich genug

kann sein das es nicht die richtige version ist
Eigentlich gehört das Linux jemand anderen und selbst der weis es nicht genau
^^

was nehme ich an gemeint war... das betriebssystem linux an sich gibts nicht... es gibt aber verschiedene distributionen... fedora, mandrivam, gentoo und einige hundert mehr

und mit linux 9.3 war wohl "suse linux 9.3" gemeint

linux is for networking, apple for working and windows for solitair

hi,

http://lists.suse.com/archive/suse-slox-e/2003-Jun/0142.html

edith:
mit "tune2fs -l /dev/hdxy" solltest nähere info´s über intervall, next check,.. sehen...
(xy anpassen

)

lg,
hariw

Er :..kommt etwas vom Alkohol beinträchtigt Heim, geht ins Schlafzimmer, hat ein Schaf unterm Arm und lehnt sich an den Türstock...:
Er : Schau, dass is die Sau, die ich immer f***, wenn du nicht willst...
Sie: Aber Schatz, wie redest du??? Und Überhaupt, das ist keine Sau, sondern ein Schaf!
Er : Halt´s z´amm - wer red denn mit dir?

10.01.2006, 15:32 Uhr - Editiert von hariw, alte Version: hier

Wobei da eh was falsch rennt...

Dauern die Checks bei ext3 noch immer so lange ? Oder kann es sein, daß er ext2 einsetzt ???

So oder so, wenn er auf reiser wechselt, hat er den Streß nicht mehr.

So oder so, wenn er auf
reiser wechselt, hat er den Streß nicht mehr.

ha. ha. ha. *hust*. wie ich die zealots liebe

Es gibt einige gute Gründe auf Reiser zu wechseln. Der von dir genannte ist keiner.

Und hier noch ein bisschen weiterführende Lektüre: http://linuxmafia.com/faq/Filesystems/reiserfs.html

Google-Pagerank-Abuseage:
mirror
random crap
slackware mirror

Dann lies nochmal...
Es gibt viele Gründe, weg von nicht-journalling-Dateisystemen zu wechseln. Ich bin kein Selbstmörder, und verwende drum kein ext3... Ext2 war rock-solid, allerdings eben net journalling.

Drum war meine Vermutung, daß der Dateisystemcheck eine Folge von einer ext2-Installation ist (Keine Ahnung, ob ext3 noch immer ein fsck alle x tage macht) - und drum die Empfehlung zu reiser.

Reiser's fschk sieht so aus wie in deiner Kopie beschrieben - nur hast du den bekannten Thread gekürzt - oder du hast in von einer Website, wo er verkürzt dargestellt wird

.

Denn das Problem von Inkonsistenzen bei reiserfs wird genau in einem Fall kritisch: Wenn du ein reiserfs in einem reiserfs hast via loop-Device - dann kann der Mischmasch wirklich leichter entstehen.

Allerdings ist die Chance relativ gering, daß er ein mount -o loop macht, wenn ich die Frage sehe - und es gibt seeehr wenig sinnvolle Gründe, ein journalling-fs in einem journalling-fs zu nutzen...

Ich benutze gerne und viel ext2-loopdevices auf reiser - für meine UMLs. Reiser in reiser eigentlich nie - und ich denke nicht, daß dieser Nachteil ihn trifft. Sollte er aber derzeit echt ext2 nutzen, wäre im ein journalling-FS sicher anzuraten.

Dann lies nochmal...Es gibt viele Gründe, weg von
nicht-journalling-Dateisystemen zu wechseln.

Man erspart sich die fscks, da die _META_-Daten immer konsistent sind(oder auch nicht). Sonst fällt mir nicht viel ein. Als kleines Experiment schlage ich folgende Versuchsanordnung vor:

Du nimmst eine Partition auf einer Platte, auf der sonst nichts passiert. Du schreibst auf diese Platte parallel Daten verschiedener "Komplexität" (im Sinne von Metadaten), zB eine Datei sequentiell, nebenbei viele Directory trees die mehrere Ebenen tief sind, mit einigen kleinen Dateien drin. Du merkst dir irgendwie (andere partition, via fsync gesyncte Datei) wie weit du gekommen bist und drückst dann einfach auf Reset. Nachdem der Rechner wieder oben ist schaust du welche Dateien/Daten in welcher Form noch intakt (Inhalt!) und vorhanden sind.

Das ganze versuchst du mit ext2, ext3 und reiser (reiser4 wär besonders interessant, das soll ja jetzt auch intakte Dateiinhalte garantieren). Nach dem ersten Durchlauf das ganze nocheinmal, aber diesmal statt Reset Netzstecker ziehen.

Ich kann dir versprechen dass der unterschied zwischen ext2 und ext3 nicht gravierend sein wird (wobei ich nicht weiss ob ext2 auch standardmaessig ein 5-sekündiges commit-intervall hat, und das ist ja ein wesentlicher Faktor bei diesem Test). Und ich bin mir ziemlich sicher, dass reiser schlechter abschneiden wird.

Ich bin kein Selbstmörder, und verwende drum kein ext3...

Das musst du mir erklären.

Drum war meine Vermutung, daß der Dateisystemcheck eine Folge von
einer ext2-Installation ist (Keine Ahnung, ob ext3 noch immer ein fsck alle x
tage macht)

ext3 wird so wie ext2 mit mke2fs erzeugt (bei ext3 kommt lediglich die flag '-j') dazu, und die haben standardmäßig FS checks alle 180 Tage bzw. $n mounts (wobei sich $n aus der größe der partition errechnet, wenn mich nicht alles täuscht). Anyway, anyhow, wenn das jemand als störend empfindet (ja, ist es, und es wird heutzutage IMHO nichtmehr benötigt), lässt sichs mit einem 'tune2fs -c0 -i0 /dev/hdblax' abdrehen.

und drum die Empfehlung zu reiser.

"...und wissens eh, beim diesel müssens alle paar jahr den kraftstofffilter wechseln. des is a vui a schas, nehmens besser gleich an benziner..."

Reiser's fschk sieht so auswie in deiner Kopie beschrieben - nur hast du den bekannten Thread gekürzt -
oder du hast in von einer Website, wo er verkürzt dargestellt wird .Denn das
Problem von Inkonsistenzen bei reiserfs wird genau in einem Fall kritisch:
Wenn du ein reiserfs in einem reiserfs hast via loop-Device - dann kann der
Mischmasch wirklich leichter entstehen.Allerdings ist die Chance relativ
gering, daß er ein mount -o loop macht, wenn ich die Frage sehe - und es gibt
seeehr wenig sinnvolle Gründe, ein journalling-fs in einem journalling-fs zu
nutzen... Ich benutze gerne und viel ext2-loopdevices auf reiser - für meine
UMLs. Reiser in reiser eigentlich nie - und ich denke nicht, daß dieser
Nachteil ihn trifft. Sollte er aber derzeit echt ext2 nutzen, wäre im ein
journalling-FS sicher anzuraten.

Der schlechte reiserfsck ist nur ein zusätzliches Problem von Resier. Den Teil mit den Problemen bei Stromausfällen hast du komplett übersehen, oder?

Google-Pagerank-Abuseage:
mirror
random crap
slackware mirror

Nochmal...

Reiserfs hat kein Problem bei Stromausfällen. Das Dateisystem bleibt konsistent. Das bedeutet natürlich nicht, daß die Daten in den Files selbst in Ordnung sein müssen...

Nur hast du eben bei einem defekten File weitaus weniger Schaden als bei einem defekten Filesystem. In den einem Fall reicht es, das defekte File zu recovern (und ich denke nicht, daß es heute noch einen einzigen gibt, der keine Backups macht) - in dem anderen Fall solltest eh gleich das Dateisystem selbst neu anlegen.

Wenn ext3 übrigens verläßlich Daten halten würde, bräuchtest kein e2fsck mehr... Mir ist schon klar, daß die Aufbausemantik dieselbe ist - mir ist auch klar, daß daher implizit der Teil in den Superblocks weiterhin ein Checkpoint-Intervall kennt - allerdings vermutete ich, daß das andere Gründe hat. Das einzige, was ja wirklich für ext3 im vergleich zu anderen Journalling Dateisystemen (egal ob reiser, xfs, jfs2) spricht ist IMHO, daß man es bequem in ext2 zurückwandeln kann... Und dann braucht das als ext3 angelegte, dann als ext2 verwendete Dateisystem natürlich wieder das Check-Intervall. Wenn ext3 funktionieren würde wie versprochen, müßtest mir erst den Sinn eines e2fsck erklären

Tatsächlich wollten wir (zur Zeit der 2.4.19er-Kernel) auf unseren Servern ext3 verwenden - weil wir ihm mehr zutrauten als reiser - weil es eben auf einer soliden Basis aufsetzten. Es stellte sich allerdings durch selbstgeschriebene testprogramme [die massivst und seehr parallel im Dazeisystem werkten] bald heraus, daß es durch script nur durch Standard-operationen (Directories anlegen, mit einem Prozeß offenhalten, durch andere Prozesse das dir löschen und darin wieder rekursiv dirs anlegen, ... ) reproduzierbar war, daß der Server bei ext3 einfror... komplett. Bei reiser 100% CPU-Last - aber stabil.

Ein wichtiger Punkt ist noch, wann eigentlich ein reiserfsck notwendig sein sollte. Tatsächlich hast du - nach meiner Erfahrung - eine rund 10%ige Chance, daß es nachher komplett hin ist. Allerdings braucht man eben kein reiserfsck nach einem Stromnausfall - da bleibt es eh konsistent. Ich brauchte es nur nach einem Festplattenausfall im Raid0 - wenn ich noch versuchen wollte, etwas zu retten....

Und wenn du beinhart behauptest, daß ext2 eh super sei - und damit den Sinn von Journallenden Dateisystemen nicht anerkennst - dann laß ich den Thread hier. Es ist deine persönliche Überzeugung, die halt nicht sonderlich viel mit Produktionsumgebungs-Empfehlungen zu tun hat. Was aber nicht verwundert, da du ja bewußt verfremdete Threads zitierst oder auch mal schnell eine Thread-Reply mit "zealot", .. eröffnest.

EDIT:
Gründe gegen ext3:
Nicht online resizable... Sogar für ein vergrößern muß man das Blockdevice unmounten. Damit ist es unbrauchbar für jeden normalen Rechner, in dem man LV's für /, /usr, ... anlegt
Abstürze - getestet bei 2.4.19. Keine Ahnung, ob sich der ext3-Source stark modifizierte seitdem.
Nicht einmal die Entwickler selbst vertrauen ext3 - denn sonst hätten's net extra e2fsck implementiert - denn dessen eingeleitete Operationen müssen sich ja wohl wieder im journal abspielen, also war es sicher auch Aufwand für die Entwickler.

Gründe pro ext3:
Läßt sich als ext2 "reusen"
Kann in einem langsamen Modus auch die Daten- und nicht nur die Dateisystem-integrität sicherstellen
Hat das immutable-Bit implementiert
Mehrere Blockgrößen möglich.

Sowohl die Abstürze als auch das nicht-online-resizeable machen für mich das Dateisystem unempfehlenswert. Da lebe ich lieber mit reiser, dessen reiserfsck Probleme verursachen kann - da man es eh nie braucht.

13.01.2006, 23:28 Uhr - Editiert von gepeinigter_aon_neukunde, alte Version: hier

Nochmal...Reiserfs hat kein Problem bei Stromausfällen. Das Dateisystem
bleibt konsistent.

Also entweder möchtest du mich ärgern oder du hast den verlinkten Artikel wirklich nicht gelesen. Streng genommen hast du sogar recht, reiserfs hat kein Problem mit Stromausfällen, PC-Hardware hat Probleme mit Stromausfällen. Und Reiserfs hat Probleme mit PC-Hardware. Oder so.

Hier nochmal die relevanten Absätze kopiert:

You see, when you yank the power cord out of the wall, not all parts of the computer stop functioning at the same time. As the voltage starts dropping on the +5 and +12 volt rails, certain parts of the system may last longer than other parts. For example, the DMA controller, hard drive controller, and hard drive unit may continue functioning for several hundred of milliseconds, long after the DIMMs, which are very voltage sensitive, have gone crazy, and are returning total random garbage. If this happens while the filesystem is writing critical sections of the filesystem metadata, well, you get to visit the fun Web pages at http://You.Lose.Hard/.

[..]

Why doesn't ext3 get hit by this? Well, because ext3 does physical-block journaling. This means that we write the entire physical block to the journal, and only when the updates to the journal are committed do we write the data to the final location on disk. So, if you yank out the power cord, and inode tables get trashed, they will get restored when the journal gets replayed.

XFS and ReiserFS do what is called logical journaling. This means that if you modify the mod time of an inode, instead of writing the entire inode table block to the journal, they just write a note in the journal stating that "inode X now has a mod time of Y". This takes much less space, so you can pack many more journal updates into a single disk block.

[..]

The problem with logical journaling is that if you do have an unexpected power drop, and the storage system scribbles garbage on the inode table, there's no way to recover. In some cases, the only thing that is left to be done is mkfs and restore from backups. (Backups? You do keep backups, right?)

Wenn irgendetwas (technisch oder sprachlich bedingt) unverständlich sein sollte, gib einfach bescheid.

Ad e2fsck + ext3:

Du hast recht, im Normalbetrieb (auch bei unsauberen Shutdowns) ist kein fsck von Nöten, da sollte das Journal replaying reichen. Allerdings gibts Fälle (sehr große Block-Buffer zB im RAID-Controller [*]; kaputter RAM/CPU/Mainboard, kaputte Block devices) wo ein Check unausweichlich ist, da im FS dann inkonsistenzen Bestehen die durch einen Journal Replay nicht beheben werden können.

[*] Es gab tatsächlich RAID-Controller mit 64MB und mehr Write-Cache am Controller ohne Battery backup. Was glaubst du was passierte wenn das Ding direkt nach sehr schrebintensiven Tasks stromlos wurde?

Ad checkintervalle:

Die sind heutzutage auch bei ext2 nichtmehr notwendig. Im superblock gibts Flags für den Filesystemzustand (clean/not clean; dumpe2fs -h /dev/xxx). Wenn e2fsck beim booten bei einem Filesystem sieht das es "not clean" ist, checkt es dieses. Sonst nicht. Die periodischen FS checks sind aus einer Zeit als Kernel, FS-Treiber und Hardware noch nicht die Qualität von heute erreicht hatten, und sich Fehler "still" einschleichen konnten. (Der VIA KT133 war ein sehr schönes beispiel dafür).

Dazu auch ein Zitat von Thedore T'so, u.a. Maintainer der e2fsprogs:

Assuming perfect hardware and software, of course, these measures
should never prove necessary, but since hardware and software aren't
perfect, and data is generally very valuable, it's wise to do periodic
checks.

Und nochmal, damit das eindeutig klar ist:

Periodische FS Checks sind kein verpflichtendes Feature von ext2/ext3. Es ist ein Sicherheitsmechanismus der standardmäßig aktiviert ist. Jedem steht es frei das zu deaktivieren. Es sind keine Probleme durch das deaktivieren der periodischen Checks zu erwarten.

Ad ext3 crashes:

Kann sein, 2.4.19 ist schon "etwas länger" her. Wenns noch reproduzierbar ist, einfach ein mail an die ext3-users mailingliste mit deinem Testscript/Programm schicken, die ext3 Maintainer sind bemüht jedem zu helfen. (Ich spreche aus eigener Erfahrung).

Ad notwendigkeit von Journalling FS:

Ich mag und verwende sowohl ext2, ext3 und reiser in Produktionssystemen, jedes dort wo es seine Stärken (und Schwächen) voll ausspielen kann.

ext3 auf allen Servern die kaum/keine FS-intensiven Tasks machen.

ext2 auf Servern wo man maximale FS-performance braucht und keine Crashes/Downtimes zu erwarten sind (geringe anzahl von Dateien, hauptsächlich Zugriffe auf wenige, große Dateien), zB Datenbanken, Mirror-Server, etc.

reiserfs auf Servern, bei denen wahnsinnige (tm) Anzahlen von Dateien verwaltet werden müssen. zB ein mirror von kernel.org/git

Ich werd nur nervös wenn jemand vermitteln möchte, dass Journalling der heilige Gral ist der vor jedweger FS-Inkonsistenz schützt und sogar kaputte Platten wieder lebendig macht und jeder der was anderes verwendet wahnsinnig und irr ist (überzogen).

ad gründe gegen ext3:

Das mit dem e2fsck ist Polemik, das steht dir nicht sonderlich gut.

P.s. Wenn du möchtest können wir die von mir vorgeschlagenen Tests gern gemeinsam machen. Mich würds ziemlich stark interessieren wie es da heutuztage aussieht.

Google-Pagerank-Abuseage:
mirror
random crap
slackware mirror

Nochmal...

Klar behaupten die ext3-Jollies, daß ihr System besser sei - auch wenn dem nicht so ist.
Bleiben wir bei ihrer Argumentationskette, und schauen, was die bedeutet:

1.) Der Kernel leitet IO zur Festplatte ein
2.) Strom fällt
3.) Der DMA-Transfer passiere noch, obwohl der Memory nur noch Müll enthalte..
4.) Müll werde in's Journal geschrieben - beispiel Ändere ctime auf XYZ
5.) Das System ist gecrasht.

Nun sehen wir uns die Masse an Fehlern an, die in der Argumentationskette auftritt

.

[1] Wenn ein Datentransfer vom Controller zu den Platten passiert, ist /immer/ eine Prüfsumme (glaublich ein CRC) am Kabel dabei. Wenn schon der Strom fällt und vermüllte Raminhalte via noch funktionsfähigen Controller gelangen, müßte dessen Ram (plus die Bauteile in der Platte) noch genügend Reststrom haben, damit deren Ram net betroffen ist.
[2] Sie müßten beide noch genug Saft haben, um einen CRC korrekt zu berechnen - das halte ich für /SAU/-Unwahrscheinlich
[3] Nachher müßte noch genug Reststrom in der Platte sein, um den Platten-CRC berechnen zu können
[4] Und dann müßte noch genug Saft da sein, um das schreiben zu können...
Den Fall halte ich für hochgradigst unwahrscheinlich. Nicht ausgeschlossen - nur hochgradigst unwahrscheinlich.

EDIT: Ad Gründe gegen ext3:
Wieso der Kritikpunkt, daß sich ext3 net online resizen läßt, Polemik sein soll, mußt mir erst erklären.
Aber sehen wir weiter... Schlimm ist die Lüge der ext3er bei "Es werde nur geschrieben 'ändere zB ctime auf XYZ'." Stattdessen wird geschrieben "Ändere ctime von ABC auf XYZ", wie die ext3-er sicher wissen. Es läßt sich leicht belegen - einerseits im Reiser3-Source, andererseits wäre ein Rollback ohne der VON-INformation net möglich.

Aber ich lege noch eines drauf: Das Reordern der Platte. SCSI-Platten hatten das schon immer, bei IDE hab' ich zugegeben keine Ahnung.

Also angenommen, ich schicke einen neuen Block 1, BLock 20 und Block 2 zur Platte. Ich schicke also über den SCSI-Bus Block 1 - und die Anweisung, daß sich die Platte detached. Direkt danach sende ich Block 20 - die die Platte (weil sie noch Block 1 schreibt) zwischenpuffert. Direkt danach schicke ich Block 2 los (den sie auch noch zwischenpuffert, weil sie noch bei Block 1 ist). Sobald die Platte mit Block1 fertig ist, hat sie also Block 20 und 2 im Puffer. Dann macht sie natürlich ein Reorder - und schreibt zuerst Block2 (weil sie dann nicht positionieren muß) - und erst dann Block20.

Damit kann ich mir einen tollen Algo a la "Ich schreibe zuerst den kompletten phys. Block A und dann B" afzeichnen. Dadurch wird der IO verlangsamt - wie sogar die ext3er zugeben - und die Chance für ein reordern (das ja Gift für ext3 ist) steigt...

Die Argumentation der ext3er ist also leicht als crap enttarnt.

Journalling selbst ist aber schwerstens anzuraten.
Nachdem bdflush wohl nur alle 30-60 Sekunden schreibt, habe ich also ausreichend dirty-Pages im Ram - so auch inode-Pages. Die chance für einen Dateisystemdefekt ist bei einem nicht-journalling-fs also sehr hoch, bei einem journalling-fs weit geringer. Er ist nicht null - soweit stimme ich Dir ja noch zu.

Tatsächlich hatte ich im Laufe meiner Unixoiden-Erfahrung so einige Stromausfälle - und beim Kernel-patchen ausreichend brute-force-kills

. Bei ext2 hatte ich defekte Dateisysteme en masse, bei reiserfs nie.

Datenbank-Server auf nicht-journalling-fs betreiben hingegen halte ich für /ausgesprochen/ mutig. Hängt natürlich von der Datenbank drüber ab, aber wenn das FS selbst hin ist... Nun ja, dann nutzen im Extremfall nicht einmal die DB-Mechanismen selbst mehr was.

15.01.2006, 20:04 Uhr - Editiert von gepeinigter_aon_neukunde, alte Version: hier

Ich war gewillt mein reply jetzt auch mal mit "Nochmal" einzuleiten, lass es jetzt aber doch.

In dem Posting [1] hat Theodore T'so darauf hingewiesen, dass diese Beobachtungen von einem SGI-Entwickler gemacht wurden. Wenn du das anzweifelst bzw. als Schwachsinn abtun möchtest kannst du ihn gerne kontaktieren, ich bin mir sicher, dass er dir den betreffenden Mailverkehr forwarden kann bzw. eine Kontaktadresse der betreffenden Person geben kann. Den Power fail interrupt gibt es jedenfalls bei IRIX: [2]. Ich maße mir jedenfalls nicht an, genug wissen über die Vorgänge zu haben, um diesbezüglich irgendwelche Wahrscheinlichkeiten treffen zu können, ich kanns höchstens testen.

Deinen Ausführungen über Reordering, Lügen der ext3-Developer und sonstiger "crap"-Aussagen konnte ich nur bedingt folgen, kann dir aber keine definitiven Antworten geben da ich mich mit der Materie nicht gut genug auskenne.

Wenn ich Theodore T'so richtig verstanden habe, ist das Haupt"problem" von reiser und xfs, das sie mehrere Inode-Aktualisierungen in einen Journal-Block (viele aktualisierungen in 512 Byte) schreiben, wohingegen ext3 einfach die aktualisierten Blöcke als solches komplett (512 Byte (oder mehr) pro Aktualisierung) ins Journal schreibt. Es macht schon einen Unterschied ob bei einem Crash mit einem "verdampften" Block 1 Update oder 3-5 Updates (weiss nicht wieviel Updates reiserfs in einen Block reinbringt) verloren gehen.

Ad Polemik:
Das mit dem resizen war keine Polemik, sondern ein Fakt, und das hab ich auch nicht bemängelt. Mir gings um deine Aussage, dass "nicht mal ext3 Entwickler ext3 vertrauen würden, weils ja ein funktionierendes e2fsck gibt". Das ist einfach nurmehr Schwachsinn.

Da würde sich dann "Reiserfs ist total super, weil für das gibts kein gscheits fsck [3], weils ja nicht gebraucht wird!" nahtlos einreihen

Ad [bp]dflush:

Der hat damals (2.4) wie heute ein commit intervall von 5 sekunden als Standardwert, siehe /proc/sys/vm/dirty_writeback_centisecs bei modernen Kernel.

Ad journalling:

Nochmal: (jetzt aber! ha!)

Du gewinnst bei Journalling genau die Zeit fürs fsckn. Sonst nix. Überhaupt nix. Dateien/Directories die in einem kritischen Zeitpunkt angelegt wurden können sowohl beim Journalling fs als auch beim "nicht journalling fs aber fsck nach dem crash" da sein _ODER_ nicht. (oder ein bisschen, wenn man sehr viel pech hat)

Viel wichtiger ist (zumindestens in meiner Wahrnehmungssphäre, bei "fundamentalistischen" usern schaut das anscheinend etwas anders aus) was mit dem Inhalt von Dateien passiert:

Bei ext2 [6], ext3 mit data=writeback und reiser3 hast du in den Dateien die schreibend geöffnet waren mit hoher Wahrscheinlichkeit Müll drinnen.[4] (Ich sag nur ^@^@^@ [5])

Bei ext3 mit data=ordered (default mode) hast du entweder den Zustand vor oder nach dem Write.

Ad nichtjournalling:

Vielleicht ist das einfach nur das Verständnigsproblem: Natürlich mach ich auf den Servern auf denen ich kein journalling FS verwende nach jedem Crash ein fsck. Und auf Servern mit journalling ist ein


Jan 11 10:20:13 mirror kernel: EXT3-fs: md11: orphan cleanup on readonly fs
Jan 11 10:20:13 mirror kernel: ext3_orphan_cleanup: deleting unreferenced inode 360361
Jan 11 10:20:13 mirror kernel: ext3_orphan_cleanup: deleting unreferenced inode 360352
[..]
Jan 11 10:20:13 mirror kernel: EXT3-fs: md11: 14 orphan inodes deleted
Jan 11 10:20:13 mirror kernel: EXT3-fs: recovery complete.
Jan 11 10:20:13 mirror kernel: EXT3-fs: mounted filesystem with ordered data mode.

oder


Dec 21 01:16:45 mirror kernel: ReiserFS: md0: checking transaction log (md0)
Dec 21 01:16:45 mirror kernel: ReiserFS: md0: replayed 20 transactions in 3 seconds
Dec 21 01:16:45 mirror kernel: ReiserFS: md0: Using r5 hash to sort names

genauso "dramatisch" wie:


e2fsck 1.36 (05-Feb-2005)  
/dev/hda9 was not cleanly unmounted, check  
forced.  
Pass 1: Checking inodes, blocks, and sizes  
Inode 12, i_blocks is 16, should be 2.  Fix? yes  
 
Pass 2: Checking directory structure  
Entry '0003' in / (2) has deleted/unused inode 13.  Clear? yes  
 
Pass 3: Checking directory connectivity  
Pass 4: Checking reference counts  
Pass 5: Checking group summary information  
Block bitmap differences:  -21  
Fix? yes  
 
Free blocks count wrong for group #0 (38, counted=39).  
Fix? yes  

[..]

/dev/hda9: ***** FILE SYSTEM WAS MODIFIED  *****  
/dev/hda9: 12/16 files (0.0% non-contiguous), 21/60 blocks

Genau überhauptnicht.

mfg,
michael - der sich wünschen würde weitere diskussionen darüber in persona zu führen, da das hier zunehmend anstrengend wird.

[1] vielleicht hast du nur den Link verloren? Hier nochmal: http://linuxmafia.com/faq/Filesystems/reiserfs.html

[2] SIGPWR/19 http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=man&fname=/usr/share/catman/p_man/cat5/signal.z

[3] Hans Reiser und fsck. http://lkml.org/lkml/2005/6/24/192 Lesenswerter Thread.

[4] http://www.uwsg.iu.edu/hypermail/linux/kernel/0109.3/0335.html + http://www.uwsg.iu.edu/hypermail/linux/kernel/0109.3/0654.html

[5] http://lists.debian.org/debian-user/2005/03/msg01735.html

[6] muss ich zugeben, wusste ich nicht, wär mir aber in der Zeit in der ich ext2 verwendet hab nicht aufgefallen.

Google-Pagerank-Abuseage:
mirror
random crap
slackware mirror

Heyhey, wer über Polemik schimpft...

NEIN, ich bezweifel nicht, daß SGI-Systeme einen Powerfail-Interrupt im System haben. Wobei ich auch nicht davon überzeugt bin. Ich kann nur garantieren, daß - auch die Schweineteuren - IBM-AIX-Server RS6k das nicht haben.

Wir müssen hier aber auch an die Zeit der Aussagen treffen... Als SGI - möglicherweise - das einbaute, gab es ziemlich sicher das Standard-Feature des reordern nicht. Auch eine tagged command queue des Controllers wage ich zu bezweifeln.

Die Idee eines "verdampften" Blocks - trifft nun aber Primär nicht-journalling-Systeme.

Die Idee ist im groben bei allen Journallenden FS ja wie folgt:
1.) Schreibe ins Journal, was du gleich ändern willst
2.) Ändere das
3.) Commitiere das im Journal.
Angenommen, irgendwo dazwischen fällt der Strom.
Angenommen, er fällt bei 1. Er erkennt an der Journal-Prüfsumme, daß der Eintrag nicht korrekt ist und verwirft ihn.
Angenommen, er fällt zwischen 1 und 2. Was passiert:
[a] er erkennt, daß das FS nicht clean ungemountet wurde, also journal-Check machen muß
[b] Beim Remount erkennt er, daß er Block X von A nach B ändern wollte.
[c] Block X hat aber nicht den Zustand B
[d] Also ändert er Block X auf A zurück.
Angenommen, er fällt bei 2. Das ist Äquivalent zu zwischen-1-und-2(weil die gewollte Änderung nicht stattfand).
Angenommen, er fällt zwischen 2 und 3
Dann erkennt er, daß der Update durchging - er läßt den Block also.
Angenommen, er fällt bei 3 - ident zu zwischen 2-und-3
Und nach dem abgeschlossenen Commit ist der Journal-Eintrag logisch eh weg

.

Das können /alle/ journallenden - und die Bedeutung ob logisch oder physischer Block mag den ext3-Entwicklern wichtig gewesen sein - dann aber aus einem Irrtum heraus (soll's ja schon mal gegeben haben

).

Ad Datenverlust:
Natürlich schützt dich reiser oder jfs nicht vor dem Verlust des Inhalts von Dateien - keinesfalls. ext3 Tendenziell schon. Nur... Denken wir ins Detail: Welche Dateien sind betroffen ?

Wohl nur die Dateien, die gerade "in modifcation" waren. Das Dateisystem (damit die Dateinamen, Permissions, ... sind ja im Journal bei allen gschützt). Daher bleiben nur die übrig, die gerade zum schreiben offen waren.. Wie sieht's jetzt dort aus ?

Irgendwo im Programmcode passierte ein int fd=open("bubu", O_RDWR) - oder die Datei wurde via mmap geöffnet. Mehr Varianten gibt's ja nicht. Sehen wir sie uns an:
Beim open (oder fopen) werden ja alle writes durch die stdio.h gecached - und erst nach blocksize bytes geschrieben. Geschrieben ? Sie kommen mal in den buffer cache - und der wird je nach Einstellung durch bdflush von mir aus alle 5 Sekunden geschrieben. Damit hast aber wirklich gute Chancen, daß folgendes passiert:
Vorher sei in der Datei "A B C" gestanden. Dein Programm öffnet, macht ein lseek() an Position "B" und will "D F" schreiben - also "A D F" erzeugen. Durch ext3 hast jetzt die zugegeben gute Chance, daß zB das "D" noch garantiert geschrieben werden kann - und nur das "F" verloren geht ("A"," " und "C" seien jeweils einen block groß). Damit hättest danach - aus Dateisystemsicht korrekt - "A D F" in der Datei stehen - also weder das alte noch das neue. Das halte ich für gleich schlecht wie komplett zerstörte Dateien, von denen nur noch Größe und Permissions da sind. Man mag im Detail drüber streiten, im Zweifel gebe ich dir sogar Recht, daß ein "A D F" besser sein kann als ein "MÜLL". Im Endeffekt sind alle betroffenen Dateien /fragwürdig/.

Nehmen wir noch den anderen Fall - via mmap. Das geht nun direct in den Buffer cache. Soweit sogut. Dort kann es aber noch leichter passieren, daß spezielle Punkte der Datei "hot" sind, also manche Blöcke dauernd überschrieben werden - und damit genauso die Datenverlust-gefahr besteht.

Meiner Meinung nach - viell. durch alte Systeme geprägt - soll ein journal /das Dateisystem/ - also nicht die einzelnen Dateien schützen. Damit soll gewährleistet sein, daß sich das Dateisystem /immer/ mounten läßt. Alle Systemdateien (zb in /bin, /sbin) hast eh read-only gemountet - damit kann dort überhaupt nix verlorengehen. Gleichzeitig garantierst du damit in deinem System einen Zustand, der immerhin recoverbar ist.

Den Schutz von konsistenten Dateien kann dir aufgrund der Applikationslogik und der OS-Caches kein Journalling-FS garantieren. Angenommen, SGI hätte diesen PowerFail-Interrupt - und das Betriebssystem hat gerade 100 "dirty Pages" im Ram gecached. Was soll mit den 100 Pages beim Powerfail-Interrupt passieren ? Schreiben darf's ja nix mehr - weil ja in ein paar millionstel Sekunden das Ram zusammenbricht. Also muß es sie in's Grab mitnehmen. Seehr pathetisch - aber leider auch kein garantiert sauberes System.

Es gäbe IMHO eine einzige Variante, wie du ext3 wirklich sauber hinkriegst - wenn du mount -o sync spielst. Kein Cache=Immer direkter FS-Zugriff=sehr gute Chance, auch den Dateiinhalt zu retten. Da kann reiser nicht hin, JFS nicht hin - da hat ext3 die Nase vorne. Zugegeben. Aber /nur/, wenn du mit "-o sync" fahren kannst. Das kannst du uU wenn du ein cooles Storage-Kisterl mit 150MB/sec dran hast (aber dann hast i.d.R. eh ein SAN - und das FS von dort) - oder wenn Performance kein Thema ist.

Ich persönlich halte - auch aus den OS-Cache-Überlegungen - die data=ordered-Gschicht für ein großes Gschichterl. Net wertlos, aber auch nicht der 100%-Hit. Als Chancensteigerung nicht wertlos - aber auch nicht viel wert. Versteh' mich nicht falsch, mir ist auch wenig mehrwert lieber als gar keiner - nur bevorzuge ich da eher die chance eines online-resizens als das Chancen-Steigern um ein paar %.

Ach ja, ad ext2 - hier kam es schon öfters vor, daß sich ein FS schlicht nicht mehr mounten ließ nach einem Stromausfall... Das hatte ich bei reiserfs nie.

15.01.2006, 23:07 Uhr - Editiert von gepeinigter_aon_neukunde, alte Version: hier

Ha super danke

Damit lässt sich was machen!!!

EDIT: gilt für beide

Dave

10.01.2006, 15:42 Uhr - Editiert von -"Dave"-, alte Version: hier

Dieses Forum ist eine frei zugängliche Diskussionsplattform.
Der Betreiber übernimmt keine Verantwortung für den Inhalt der Beiträge und behält sich das Recht vor, Beiträge mit rechtswidrigem oder anstößigem Inhalt zu löschen.
Datenschutzerklärung