Diagnosetool

[-=DatHirschi=-]

Servesa!

Gibts sowas wie Scandisk auch als 3rd-PartyApp? Evtl. sogar als planbare App?

 

[itari]

Was soll denn plattenmäßig gescannt werden? Dateisystem oder Plattenfehler? Plattenfehler geht mit SMART und Dateisystem mit fsck (welcher ja beim Start immer ausgeführt wird und seine Meldungen in der /var/log/messages hinterlässt). Oder was wolltest genau testen.

Den scandisk gibt es unter Vista nicht mehr ... weiß eigentlich nicht mehr genau, was der noch alles gemacht hat. Die Alternative 'chkdsk' ist vergleichbar zum fsck ...

Itari

 

[-=DatHirschi=-]

FSCK? Ist mir neu...bitte weitere Infos!

 

[jahlives]

FSCK? Ist mir neu...bitte weitere Infos!

Bitte sehr http://linux.die.net/man/8/fsck und http://linux.die.net/man/8/e2fsck
@itari
Was ist eigentlich der Unterschied zwischen fsck und e2fsck? Scheinen ja beide sowohl mit ext2 als auch ext3 zu funzen

 

[PeterG]

Hi,
jedenfalls hier wird e2fsck beim Start anscheinend nicht automatisch ausgeführt, jedenfalls findet sich im Log der Hinweis, dass der Check dranwäre, weil das Volume schon zu oft ohne check gemountet worden sei. Allerdings läßt sich der Check im laufenden System ja nicht machen...

Gruß
Peter

 

[-=DatHirschi=-]

Also bei mir gibts auch nur einmal nen Konsistenztest und dann nix mehr...

 

[itari]

Ja da hab ich mich wohl vertan. Hab -q mit -p verwechselt. Es findet also beim Booten kein wirklicher File-System-Check statt. Man muss den selbst einbauen oder seine DS wegschmeißen. Anleitung hatte ich ja schon mal gegeben - zu beidem

Itari

 

[PeterG]

Hi,
wäre das aber nicht eine Sache, die "ab Werk" laufen müßte? Wenn ich e2fsck manuell anstoße, sehe ich ja, dass eine Menge Fehler vorhanden sind (nichts Gravierendes offenbar, aber dennoch); das müßte doch automatisch kontrolliert und korrigiert werden IMHO (danke für den Hinweis auf Deine Anleitung für den Einbau, aber angesichts der damit verbundenen Risiken würde ich das doch gerne dem Hersteller überlassen). Ich bin ziemlich erstaunt, dass so eine für die dauerhafte Systemstabilität wichtige Prüfung offenbar gar nicht erfolgt. War das noch nie Thema? Sollte Synology vielleicht nahegebracht werden, zumindest würde mich interessieren, warum das nicht für nötig gehalten wird.

Gruß
Peter

 

[-=DatHirschi=-]

Hat jemand ähnliches zu berichten?

 

[jahlives]

Es geht ab Werk nicht so einfach, weil man nur Dateisysteme prüfen kann die nicht gemounted sind. Wenn du also die Systempartion prüfen wolltest, dann dürfte die nicht eingebunden sein. Das ist bei einem laufenden System nicht zu machen. In dem Moment wo du das / unmountest würde sich die DS gleich verabschieden.
Darum sind solche Prüfungen auf Systempartitionen nur mit dem Ausbau der Platte zu machen. Dazu baust du due Platte am besten in einen PC ein und bootest ein LiveLinux von CD oder DVD. Dann ist es kein Problem auch die Systempartition schreibend von Fehlern zu befreien.
Wie gesagt, wenn von der Part gebootet wurde, dann ist dies nicht möglich.
Alle anderen Partition kannst du manuell mit der DS einfach prüfen. Am besten dazu die jeweilige Partition unmounten (umount) und dann auf der Konsole den check drüber laufen lassen. Da solche Test je nach Parametern sehr lange dauern können empfehle ich die Installation von screen (via ipkg). Damit wird des möglich den Befehl in einer eigenen Shell Instanz abzusetzen, diese Instanz zu verlassen und auf der normalen Shell weiterzuarbeiten. Du kannst dich auf der Hauptshell sogar ausloggen (exit) und dann nach einer Neuanmeldung via screen -r wieder auf die Shell mit dem Befehl (ist im Hintergrund immer gelaufen) zugreifen.

 

[PeterG]

Hi,
danke für die Erläuterung. Wenn ich das richtig verstehe, ist Linux also zu einer Prüfung des Dateisystems des Bootsystems überhaupt nicht in der Lage? Das ist allerdings überraschend; derartige Prüfungen z. B. nach einem Systemabsturz hatte ich - da selbst Windows dazu in der Lage sit - eigentlich für selbstverständlich gehalten...

Gruß
Peter

 

[jahlives]

Auf Fehler prüfen kannst du schon. Es fragt sich nur ob du sie auch korrigieren kannst weil / als ro eingebunden wird bei solchen tests. Und eingebunden muss sie sein, weil dort die Befehle für die checks liegen. Man müsste versuchen alle benötigten Befehle durch ein rc Script in das RAM Verzeichnis zu laden. Dannj sollte es auch möglich sein / zu un-mounten

 

[itari]

Der fsck und seine Anverwandten können selbstverständlich auf ein ro gemoutetes wie auch ein nicht-gemoutetes Dateisystem schreibend zugreifen (greifen raw zu). Ist doch genauso wie das Programm, welches das Dateisystem erstellt (mkfs). Es ist normalerweise völlig üblich beim Starten einen fsck auf das root-Dateisystem zu machen, dafür gibt es bei anderen Systemen den init s-Modus, den es leider auf der DS dank busybox nicht gibt.

Mein Vorschlag ist eigentlich die einfachste Lösung ... warum sowas nicht direkt von Synology eingebaut wird, ist mit auch nicht ganz klar (bei mir läuft das nu schon seit mehr als einem halben Jahr absolut zufriedenstellend).

Noch was zum File-System-Check ganz allgemein. Wenn man sich nicht an den Fehlermeldungen stört, dann kann man den Check auch getrost sein lassen, weil man ja mit ext3 ein jounalisierendes Dateisystem hat. Das Journal hat ja den Zweck, Inkonsistenzen erst gar nicht entstehen zu lassen. Wir kennen das ja auch von Windows-NTFS ... wie selten da ein File-System-Check erfolgt und wie häufig das bei FAT32 der Fall ist, wenn wir den Rechner einfach ausschalten.

Itari

 

[smulg]

... Da solche Test je nach Parametern sehr lange dauern können empfehle ich die Installation von screen (via ipkg). Damit wird des möglich den Befehl in einer eigenen Shell Instanz abzusetzen, diese Instanz zu verlassen und auf der normalen Shell weiterzuarbeiten. Du kannst dich auf der Hauptshell sogar ausloggen (exit) und dann nach einer Neuanmeldung via screen -r wieder auf die Shell mit dem Befehl (ist im Hintergrund immer gelaufen) zugreifen.

Reicht es nicht aus dem Befehl noch ein kaufmännisches "Und" (&) anzuhängen? Dann läuft doch der Befehl auch im Hintergrund weiter, auch wenn man sich abmeldet. Und die Shell ist auch wieder frei für weitere Befehle.

 

[jahlives]

@smulg
jop ein & würde reichen den Prozess in den Hintergrund zu ballern. Nur wirst du dann die Ausgabe des Prozesses nicht sehen (z.B. wieviele Fehler wurden gefunden und korrigiert)

 

[smulg]

Hmmm, stimmt.
Aber findet man die Ergebnisse nicht in den messages?
Oder könnte man nicht den Ausgabepfad für die Rückmeldungen vom Befehl ändern und das alles in eine Datei schreiben lassen?

 

[jahlives]

Klar geht das. Das itari in seinem Beispiel des Checks in rc ja auch so gemacht. Es hat die Ausgabe der Befehle an eine Datei geleitet