Re(8): 60 tage disc check

60 tage disc check (22 Beiträge, 937 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

Re: 60 tage disc check (Raydoo am 10.01.2006, 15:24:33)

Re(2): 60 tage disc check (-"Dave"- am 10.01.2006, 15:28:26)

Re(3): 60 tage disc check (Raydoo am 10.01.2006, 15:33:39)

Re(3): 60 tage disc check (sharky2 am 10.01.2006, 18:51:47)

Re: 60 tage disc check (hariw am 10.01.2006, 15:29:37)

Re(2): 60 tage disc check (gepeinigter_aon_neukunde am 10.01.2006, 16:06:33)

Re(3): 60 tage disc check (Robe am 11.01.2006, 17:21:10)

Re(4): 60 tage disc check (gepeinigter_aon_neukunde am 13.01.2006, 13:11:59)

Re(5): 60 tage disc check (Robe am 13.01.2006, 16:37:41)

Re(6): 60 tage disc check (gepeinigter_aon_neukunde am 13.01.2006, 23:19:44)

Re(7): 60 tage disc check (Robe am 15.01.2006, 18:31:20)

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

Re(9): 60 tage disc check (Robe am 15.01.2006, 21:37:32)

Re(10): 60 tage disc check (gepeinigter_aon_neukunde am 15.01.2006, 23:06:01)

Re(2): 60 tage disc check (-"Dave"- am 10.01.2006, 15:36:52)

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