Re(10): 60 tage disc check

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

Re(8): 60 tage disc check (gepeinigter_aon_neukunde am 15.01.2006, 19:55:57)

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

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

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