ext3: Daten einer nicht abgeschlossenen Transaktion retten

[Jaecko]

Verwendet wurde ein Eintrag in der fstab:

/dev/disk/by-uuid/(ewiglangeUUID)  /media/USBDisk  ext3  defaults,noatime 0 0

ext3 hätte mir halt in Sachen Geschwindigkeit gegenüber NTFS gefallen. Nur wenn sowas öfter vorkommt, dass da einfach mal Daten nicht endgültig geschrieben werden und man das als Benutzer erst dann merkt, wenn die Daten nach nem Neustart weg sind... da bleib ich lieber beim (unter Linux langsamen) NTFS (zumal ich da dann nochmal 16GB mehr Speicher hab, die sonst fürs Journal draufgehen würden).

Das mit dem extundelete probier ich mal.

[schorsch_76]

ext3 und ext4 sind die am meisten und am besten getesteten Filesysteme unter Linux. Ich tippe eher auf ein Problem mit der USB-Sata Bridge. Der Raspi hat auf seinem USB Port nicht viel Leistung. Für eine Festplatte kann das problematisch werden und dann den USB-Sata Controller in die Knie zwingen.

[markusj]

Nur wenn sowas öfter vorkommt, dass da einfach mal Daten nicht endgültig geschrieben werden und man das als Benutzer erst dann merkt, wenn die Daten nach nem Neustart weg sind... da bleib ich lieber beim (unter Linux langsamen) NTFS

Naja, im wesentlichen ist das eine Frage der Mountoptionen. Ich weiß nicht wie NFTS-Partitionen per default eingebunden werden, aber du kannst die Eigenschaften von ext[2,3,4] in einem hohen Maße beeinflussen. Für Paranoide: data=journal (macht ext4 aber langsamer).
Wenn du nach einem Absturz Probleme mit plötzlich leeren (0-Byte) Dateien hast, solltest du außerdem die Option auto_da_alloc nutzen.

mfG
Markus