chkdsk und ntfs
- Ersteller dedi
- Erstellt am
ich hab da mal nen problem...
im mcse-board gibt es einen mod, der behauptet, das ntfs beim neustart nach einem aufhänger / reset / stromausfall / atom-schlag ein chkdsk benötigt (bei einem journaling file system
)
jetzt die frage:
hat einer von euch schonmal erlebt, das chkdsk bei win 2k oder xppro nach einem aufhänger o.ä. von selber startet? (auf ntfs-volumes?)
im mcse-board gibt es einen mod, der behauptet, das ntfs beim neustart nach einem aufhänger / reset / stromausfall / atom-schlag ein chkdsk benötigt (bei einem journaling file system
)jetzt die frage:
hat einer von euch schonmal erlebt, das chkdsk bei win 2k oder xppro nach einem aufhänger o.ä. von selber startet? (auf ntfs-volumes?)
Zuletzt bearbeitet:
nein hatte ich noch nicht (NT4/W2k Pro) - und das obwohl manche Mitarbeiter hier der Meinung sind, herunterfahren VOR dem Auschalten ist was für Schwächlinge 
kann aber trotzdem sein - wenn Win der Meinung ist, dass das Journal beschädigt ist oder nicht korrekte Einträge enthält, DANN kommt chkdsk
cu GarfieldX
kann aber trotzdem sein - wenn Win der Meinung ist, dass das Journal beschädigt ist oder nicht korrekte Einträge enthält, DANN kommt chkdsk
cu GarfieldX
-cb-
Grand Admiral Special
- Mitglied seit
- 11.11.2001
- Beiträge
- 4.884
- Renomée
- 69
Original geschrieben von dedi
ich hab da mal nen problem...
im mcse-board gibt es einen mod, der behauptet, das ntfs beim neustart nach einem aufhänger / reset / stromausfall / atom-schlag ein chkdsk benötigt (bei einem journaling file system
jetzt die frage:
hat einer von euch schonmal erlebt, das chkdsk bei win 2k oder xppro nach einem aufhänger o.ä. von selber startet? (auf ntfs-volumes?)
Selbstverständlich gibt es das.
Du bekommst dann beim booten einen Bildschirm in dem eine Meldunge kommt: Einer der Datenträger muss auf Konsistenz überprüft werden und dann rattert chkdsk durch.
Du kannst auch selber das System veranlassen beim nächsten neustart einmal die Laufwerke überprüfen zulassen, da Win2k/XP für chkdsk die Laufwerkszugriffe aufheben muss, was aber z.b. bei der Systempartition nicht möglich ist, wird chkdsk beim booten ausgeführt.
das mit dem absichtlichen chkdsk durchführen ist klar, nur ich hab hier schon seit monaten kein chkdsk mehr gesehen (reines ntfs-sys, das es bei sys mit einer fat-partition häufig zum chkdsk kommt ist mir klar)
und nach der definition von journaling file systems sollte sowas wie chkdsk eigentlich auch nicht nötig sein
und nach der definition von journaling file systems sollte sowas wie chkdsk eigentlich auch nicht nötig sein
Original geschrieben von dedi
und nach der definition von journaling file systems sollte sowas wie chkdsk eigentlich auch nicht nötig sein
Warum? Es muss doch eine Rutine geben, welche das Journal auf konsistenz prüft und wenn ein Fehler in dem Log gefunden wurde, dann müssen u.U. einige Aktionen rückgängig gemacht werden.
hmmm
also wo ich auch suche, ich finde nirgens einen hinweis darauf, das ein ntfs-volume auf chkdsk o.ä. angewiesen ist, um die datenkonsistenz wieder herzustellen.
alles was ich bisher gefunden habe hört sich danach an, als ob dies durch die ntfs.sys (sprich das dateisystem selber) erledigt wird.
logisch gibt es noch chkdsk, damit man sich vergewissern kann das es der platte gut geht. nur warum seh ich davon nie etwas?
also wo ich auch suche, ich finde nirgens einen hinweis darauf, das ein ntfs-volume auf chkdsk o.ä. angewiesen ist, um die datenkonsistenz wieder herzustellen.
alles was ich bisher gefunden habe hört sich danach an, als ob dies durch die ntfs.sys (sprich das dateisystem selber) erledigt wird.
logisch gibt es noch chkdsk, damit man sich vergewissern kann das es der platte gut geht. nur warum seh ich davon nie etwas?
wenn du chkdsk (oder früher Scandisk) für Fat Platten aufgerufen hast, dann musste das ganze Dateisystem erst geprüft werden, was viel Zeit in Anspruch nimmt.
Bei einem Journaling Fileystem wie NTFS sthet in den log Dateien drinne welche Aktion nicht abgeschlossen wurde, dh. das System weiß genau wo die Fehler liegen und was zu tun ist => geht ziemlich schnell und läuft beim starten im Hintergrund!
Bei einem Journaling Fileystem wie NTFS sthet in den log Dateien drinne welche Aktion nicht abgeschlossen wurde, dh. das System weiß genau wo die Fehler liegen und was zu tun ist => geht ziemlich schnell und läuft beim starten im Hintergrund!
DerKlopfer2000
Admiral Special
@dedi & Clamsie:
Es ist zwar richtig, das NTFS ein Journaling File System, das in sich schon eine Menge an Features hat, die einen softwarebedingten Datenverlust minimiert, aber nicht ausschließt. Auch Hardwaredefekte auf dem Datenträger können teilweise "überbrückt" werden.
Aber wie auch immer, das System arbeitet nur bis zu einem gewissen Grad sauber. Wenn man lange kein CHKDSK ausführt, kann die Inkonsistenz auf dem Datenträger Ausmaße annehmen, die das System nicht mehr selbst korrigieren kann (ist zwar selten, passiert aber), was dann leider Datenverlust zur Folge haben kann.
Um das mal zu zeigen, habe ich gerade mal bei mir ein 5-Phasen CHKDSK erzwungen und, obwohl ich das System gerade mal 3 Wochen laufen habe, gab es schon wieder kleinere Inkonsistenzen und freier Speicher, der als belegt gekennzeichnet war:
Normalerweise sollte es zu soetwas nicht kommen, aber wie so alles von MS arbeitet das NTFS auch nicht zu 100%. Allerdings ist das jetzt kein Grund zur Sorge. NTFS arbeitet so zuverlässig, das softwarebedingter Datenverlust nahezu ausgeschlossen werden kann. Nur dann und wann mal ein CHKDSK schadet nicht.
Es ist zwar richtig, das NTFS ein Journaling File System, das in sich schon eine Menge an Features hat, die einen softwarebedingten Datenverlust minimiert, aber nicht ausschließt. Auch Hardwaredefekte auf dem Datenträger können teilweise "überbrückt" werden.
Aber wie auch immer, das System arbeitet nur bis zu einem gewissen Grad sauber. Wenn man lange kein CHKDSK ausführt, kann die Inkonsistenz auf dem Datenträger Ausmaße annehmen, die das System nicht mehr selbst korrigieren kann (ist zwar selten, passiert aber), was dann leider Datenverlust zur Folge haben kann.
Um das mal zu zeigen, habe ich gerade mal bei mir ein 5-Phasen CHKDSK erzwungen und, obwohl ich das System gerade mal 3 Wochen laufen habe, gab es schon wieder kleinere Inkonsistenzen und freier Speicher, der als belegt gekennzeichnet war:
Code:
Ereignistyp : Informationen
Ereignisquelle : Winlogon
Ereigniskategorie : Keine
Ereigniskennung : 1001
Datum : 14.09.2002
Zeit : 17:40:09
Benutzer : Nicht Zutreffend
Computer : SLAVE
Beschreibung :
Dateisystem auf C: wird überprüft.
Der Typ des Dateisystems ist NTFS.
Die Volumebezeichnung lautet System.
Eine Datenträgerüberprüfung ist geplant.
Die Datenträgerüberprüfung wird jetzt ausgeführt.
Kleinere Inkonsistenzen auf dem Laufwerk werden aufgeräumt.
119 nicht verwendete Indexeinträge aus Index $SII der Datei 0x9 werden aufgeräumt.
119 nicht verwendete Indexeinträge aus Index $SDH der Datei 0x9 werden aufgeräumt.
119 nicht verwendete Sicherheitsbeschreibungen werden aufgeräumt.
CHKDSK überprüft Dateidaten (Phase 4 von 5)...
Dateidatenüberprüfung beendet.
CHKDSK überprüft freien Speicherplatz (Phase 5 von 5)...
Verifizierung freien Speicherplatzes ist beendet.
CHKDSK hat freien Speicher gefunden, der in der MFT-Bitmap (Master
File Table) als zugeordnet gekennzeichnet ist.
Windows hat Probleme im Dateisystem behoben.Normalerweise sollte es zu soetwas nicht kommen, aber wie so alles von MS arbeitet das NTFS auch nicht zu 100%. Allerdings ist das jetzt kein Grund zur Sorge. NTFS arbeitet so zuverlässig, das softwarebedingter Datenverlust nahezu ausgeschlossen werden kann. Nur dann und wann mal ein CHKDSK schadet nicht.
)Ähnliche Themen
- Gesperrt
