Ausgabe von fsck.ext2

P

Patrick82

Jungspund
Hi!

Nachdem ich auf einer meiner Festplatten, eine Samsung Spinpoint SP1614N, des öftern Datenverluste hatte, habe ich die Platte mal einer fsck.ext2 Prüfung unterzogen. Dabei kam dann folgendes raus:

MOBILE:/home/patrick # fsck.ext2 -ct /dev/sda1
e2fsck 1.38 (30-Jun-2005)
Suche nach defekten Blöcken (Nur-Lesen-Modus):erledigt 72
Durchgang 1: Prüfe Inodes, Blocks, und Größen
Durchgang 2: Prüfe Verzeichnis Struktur
Durchgang 3: Prüfe Verzeichnis Verknüpfungen
Peak-Memory: benutzter Speicher: 268k/32380k (147k/122k), Zeit: 8007.43/ 4.00/16.79
Durchgang 4: Überprüfe die Referenzzähler
Durchgang 5: Überprüfe Gruppe Zusammenfassung

/dev/sda1: ***** DATEISYSTEM WURDE VERÄNDERT *****
/dev/sda1: 11/19546112 Dateien (0.0% nicht zusammenhängend), 613372/39070072 Blöcke
benutzter Speicher: 268k/0k (52k/217k), Zeit: 8009.17/ 5.53/16.89
MOBILE:/home/patrick #


Leider kann ich mit der Ausgabe nicht viel anfangen.

Ich nehme an, dass die nachfolgende Ausgabe bedeutet, dass 72 defekte Blöcke gefunden wurden?!
Suche nach defekten Blöcken (Nur-Lesen-Modus):erledigt 72


Kennt sich evtl. jemand von Euch aus und kann mir sagen, ob ich dieser Platte noch trauen kann oder ob sich ihr "Zustand" auch weiterhin und dann evtl. rapide verschlechtern wird, sodass ich in Zukunft noch häufiger mit Datenverlusten rechnen muss?




Danke und Gruß


Patrick
 
Versuchs mal mit ext3, das ist sicherer im Bezug auf Datenverlust.

MFG

Dennis
 
1. Mal mit einem Festplattentestprogramm die Festplatte testen. Wenn eine größere Anzahl von defekten Sektoren gefunden werden, die Festplatte austauschen.
2. ext3 ist ext2 mit einem Journal und einer hash-Funktion zum Sortieren der Ordnerinhalte/Dateinamen. Keineswegs sicherer in Bezug auf Datenverlust.
 
Zuletzt bearbeitet:
Und wie wir ja wissen, sorgt das Journaling dafuer, dass man ein konsistentes Dateisystem behaelt und es somit doch sicherer ist in Bezug auf Datenverlust (zumindest bei einem Full-Journaling). :D
fsck bietet uebrigens auch die Moeglichkeit Badblock-Checks fuer eine Platte zu machen. Wenn beim Badblock-Check defekte Sektoren gefunden werden, sollte man diesen Test regelmaessig wiederholen und beobachten, ob die Anzahl der defekten Bloecke zunimmt. Solange das nicht passiert, kann man der Platte problemlos trauen. (Dann kommen die defekten Sektoren meist daher, dass man im laufenden Betrieb mal am Rechner gewacktelt hat o.ae.)
 
Und wie wir ja wissen, sorgt das Journaling dafuer, dass man ein konsistentes Dateisystem behaelt und es somit doch sicherer ist in Bezug auf Datenverlust (zumindest bei einem Full-Journaling).

Jau wofür sonst gibts denn "Journaling" :)

2. ext3 ist ext2 mit einem Journal und einer hash-Funktion zum Sortieren der Ordnerinhalte/Dateinamen.

Mir ist durchaus bekannt was ext3 ist. :P

MFG

Dennis
 
Zuletzt bearbeitet:
Die von mir gepostete "Ausgabe" stammt vom fsck.ext2, das Badblocks-Programm ist ebenfalls durchgelaufen. Deshalb kommt er, sowie ich das deute, auch auf die 72 defekten Blöcke.

Leider kann ich mir da gar nichts drunter vorstellen. Sind 72 defekte Blöcke viel bei einer 160GB Platte oder ist das durchaus "normal"?

Ihr würdet mir also ext3 mit Full-Journaling empfehlen?! Werden die defekten Blöcke dann ausgespart oder droht wieder Datenverlust sobald die defekten Blöcke beschrieben werden?



Vielen Dank für Eure Antworten,
Patrick
 
Ihr würdet mir also ext3 mit Full-Journaling empfehlen?! Werden die defekten Blöcke dann ausgespart oder droht wieder Datenverlust sobald die defekten Blöcke beschrieben werden?

Mit ext3 wird das sozusagen on-thy-fly erledigt und repariert.

MFG

Dennis
 
Auf die Platte würde ich mal
a.) Die smartmontools und
b.) ein Herstellerseitiges Plattentesttool ansetzen.
 
Ob es für meine Platte ein herstellerseitiges Überprüfungstool gibt, weiß ich nicht. Ich schau aber mal nach und laß es dann, falls vorhanden, drüberlaufen.

Jetzt noch eine dumme Frage:
Wie erstelle ich ein ext3-Dateisystem mit Full-Journaling? Ich hab meine Platten bisher immer über YaST partitioniert und formatiert. Ich kann dort zwar zu ext3 einige Optionen auswählen, aber nichts in der Richtung "Full-Journaling".

Hab auch schon "man mkfs.ext3" gelesen, aber nichts in dieser Richtung gefunden.


Edit:
Ich hab jetzt in YaST unter den fstab-Optionen doch eine Möglichkeit gefunden den Journaling Modus festzulegen. Die Optionswerte sind journal, ordered und writeback. Ich denke dass ich für Full-Journaling "journal" auswählen muss.

Dennoch habe ich noch eine Frage:
Bei meiner Festplatte handelt es sich um eine USB-Wechselplatte. Wenn ich nun den Journal-Moduls in fstab festlege, dann wird dieser Journal-Modus doch nur berücksichtigt, wenn ich immer am selben Rechner mit dieser Festplatte arbeite. Das ist aber nicht der Fall. Ich bin auch häufig in der FH und habe dort keinen Zugriff auf fstab.

Gibt es eine Möglichkeit den Journaling-Modus direkt auf der Platte "festzuschreiben"?

gruß,
Patrick
 
Zuletzt bearbeitet:
ch kann dort zwar zu ext3 einige Optionen auswählen, aber nichts in der Richtung "Full-Journaling".

Einfach mit der Option "data=journal" mounten.

MFG

Dennis
 
DennisM schrieb:
Jau wofür sonst gibts denn "Journaling" :)
journaling ist im server-betrieb vorteilhaft. und zwar für den fall wenn irgendne hardware abraucht, das FS unsauber hinterlassen wird. dann hat man bei ext3 einen zeitvorteil, der sich bei größeren plattenarrays durchaus im stunden-bereich bewegen kann. ext3 spielt das journal ziemlich schnell ( in ein paar sekunden) wieder ein, dann ist die kiste betriebsbereit. ext2 macht in dem fall erstmal ne stunde lang den kompletten check beim hochfahren des systems.
 
Das war eher ironisch gemeint :)

MFG

Dennis
 
Wie mountest du in der FH die Platte? AFAIK sollte es, wenn du dort die Platte händisch mountest mit der richtigen Option für mount klappen. (So in etwa mount -t ext3 /dev/USBPladde /wohin/auchimmer -o data=journal oder ähnlich. Im Zweifel siehe man mount)

Edit: Mist, zu langsam ^^
 
Bâshgob schrieb:
Wie mountest du in der FH die Platte? AFAIK sollte es, wenn du dort die Platte händisch mountest mit der richtigen Option für mount klappen. (So in etwa mount -t ext3 /dev/USBPladde /wohin/auchimmer -o data=journal oder ähnlich. Im Zweifel siehe man mount)

Edit: Mist, zu langsam ^^


In der FH ist SuSE 9.3 installiert und dort läuft das mounten automatisch ab.
Deshalb die Frage, ob man den Journaling-Modus irgendwie auf der Platte festschreiben kann, sodass eines fremdes System (z.B. ein PC in der FH) die Platte mit den richtigen Optionen automatisch mountet oder macht SuSE das sobald einmal "data=journal" verwendet wurde, immer richtig?



gruß,
Patrick
 
Dann bleibt dir in der FH erstmal nur ein neugieriger Blick in die /etc/mtab über.
 
Leg das mal in der /etc/fstab fest, einfach zu den Optionen data=journal hinzufügen.

MFG

Dennis
 
@DennisM:

Patrick82 schrieb:
Bei meiner Festplatte handelt es sich um eine USB-Wechselplatte. Wenn ich nun den Journal-Moduls in fstab festlege, dann wird dieser Journal-Modus doch nur berücksichtigt, wenn ich immer am selben Rechner mit dieser Festplatte arbeite. Das ist aber nicht der Fall. Ich bin auch häufig in der FH und habe dort keinen Zugriff auf fstab.

Nützt ihm ergo in der FH nichts.
 
Ich hab die fstab jetzt angepasst bzw. YaST hat das für mich erledigt.
Ich beschreibe jetzt einfach mal die Platte und schau dann in der FH ob ich Zugriff auf mtab und fstab habe und sehe nach wie der "Automounter" meine Platte dort einbindet.


Danke für Eure Hilfe!


gruß,
Patrick
 

Ähnliche Themen

Filesystem von Truecrypt-Container beschädigt !?

Problem mit Festplatte

Zurück
Oben