Konsolen-Befehl, um Dateien einzeln zu kopieren und gleich wieder zu löschen?
- Ersteller stolley
- Erstellt am
Aldo01
Aktives Mitglied
- Dabei seit
- 30.01.2010
- Beiträge
- 635
- Reaktionspunkte
- 135
Indem die defekte Grafikkarte einen Kernel-Panik verursacht und/oder das komplette System einfriert..
Dann werden gerade geöffnete Daten nicht zurückgeschrieben und das Filesystem ist u.U. inkonsistent.
Die Dateien somit fehlerhaft.
Kann man auch simulieren indem man einfach mal USB-Sticks oder externe Festplatten mit denen man gearbeitet hat einfach rauszieht ohne sie vernünftig auszuwerfen.
Kann gut gehen, muss aber nicht.
Grafikkarte hin -> Fehler auf dem Bus -> Fehler im Speicher (DMA) -> Fehler auf der Platte.
Halt ich zwar auch für weit hergeholt, aber so ein Bus ist nicht unverwüstlich.
Muss nur zum PCIe Transaction Timeout kommen wegen Bitfehlern auf dem Bus und der SATA Controller bricht ein Kommando ab.
Aber wie gesagt, muss nicht so sein.
Halt ich zwar auch für weit hergeholt, aber so ein Bus ist nicht unverwüstlich.
Muss nur zum PCIe Transaction Timeout kommen wegen Bitfehlern auf dem Bus und der SATA Controller bricht ein Kommando ab.
Aber wie gesagt, muss nicht so sein.
Um die hier genannten Fehler zu erzeugen, müssten doch auch Fehler auf die Platte geschrieben worden sein. Nur Lesen macht ja erst mal nichts.
Ich wollte mit meiner Anmerkung darauf hinaus, dass der Grundfehler nicht unbedingt in der Grafikkarte liegen muss. Vielleicht will die Festplatte ja nur repariert werden.
Ich wollte mit meiner Anmerkung darauf hinaus, dass der Grundfehler nicht unbedingt in der Grafikkarte liegen muss. Vielleicht will die Festplatte ja nur repariert werden.
Aldo01
Aktives Mitglied
- Dabei seit
- 30.01.2010
- Beiträge
- 635
- Reaktionspunkte
- 135
HFS+ ist ein Dateisystem mit Journal.
Das ist gleichzeitig der Schwachpunkt.
Beim Speichern einer Änderung wird die aktuelle Version des Dokumentes in einem Rutsch in eine neue Datei geschrieben, danach die frühere Version gelöscht und der Dateiname auf die neue Datei übertragen.
Wenn genau in dem Zeitpunkt dazwischen der Rechner wegbricht hast du in inkonsistentes Filesystem mit defekten Dateien.
Siehe http://de.wikipedia.org/wiki/Journaling-Dateisystem#Problematik_von_Dateisystemaktualisierungen
XFS ist z.B. ein extrem performantes Filestem weil es viel im Speicher puffert um Schreibzugriffe auf die langsame Festplatte möglichst abzufangen.
Und aus diesem Grund extrem anfällig für Stromausfälle etc.
HFS+ ist da etwas robuster, aber Wunder vollbringen kann es auch nicht. ;-)
Und der Mac liest ja nicht nur: Es wird auch versucht die Daten nach zugriffshäufigkeit zu optimieren und auf schnelle (Außenbereiche) zu verschieben.
Siehe Fusionsdrive.
Also kannst du nicht davon ausgehen daß nur gelesen wird.
Und auch SSDs "optimieren" im Hintergrund selbstständig rum und verschieben Daten physisch ohne daß das OS davon was mitbekommt.
Genau, so ist es leider schon des öfteren geschehen!
Seid ihr nun sicher, dass mit dieser Methode i/o Fehler aufgedeckt werden?
Dann würde ich da dran bleiben...
Ich würde:
- zuerst ein Backup aller Daten auf einem neuen Medium machen (falls kaputte Daten dabei sind, willst du dein altes Backup zur Sicherheit noch haben, also nicht überschreiben)
- mit einem Hardware-Test die Platte auf physikalische Fehler überprüfen, ich nehme dazu immer ein Linux-Livesystem, Apple liefert den Apple Hardware Test mit
- im Single User Mode starten und versuchen, den Dateisystemkatalog zu reparieren. Dazu gibt man nach dem Start
ein, Achtung: US-Tatstaturbelegung. Man kann das mehrmals laufen lassen.
- Wenn möglich, das defekte Gerät einfach icht mehr nutzen, bis die GraKa ausgetaischt wurde (geht natürlich nur mit nem Ersatzrechner...)
Zu den genannten Punkten gibt es etliche Anleitungen hier im Forum, einfach mal nach AHT, Apple Hardware Test fsck usw. suchen.
Da ich nur alte Macs besitze, kann ich zu Spezifika bei Geräten mit OS X > 10.6 leider nicht konkreter helfen...
- zuerst ein Backup aller Daten auf einem neuen Medium machen (falls kaputte Daten dabei sind, willst du dein altes Backup zur Sicherheit noch haben, also nicht überschreiben)
- mit einem Hardware-Test die Platte auf physikalische Fehler überprüfen, ich nehme dazu immer ein Linux-Livesystem, Apple liefert den Apple Hardware Test mit
- im Single User Mode starten und versuchen, den Dateisystemkatalog zu reparieren. Dazu gibt man nach dem Start
Code:
/sbin/fsck -fy- Wenn möglich, das defekte Gerät einfach icht mehr nutzen, bis die GraKa ausgetaischt wurde (geht natürlich nur mit nem Ersatzrechner...)
Zu den genannten Punkten gibt es etliche Anleitungen hier im Forum, einfach mal nach AHT, Apple Hardware Test fsck usw. suchen.
Da ich nur alte Macs besitze, kann ich zu Spezifika bei Geräten mit OS X > 10.6 leider nicht konkreter helfen...
Olivetti
Aktives Mitglied
- Dabei seit
- 09.12.2005
- Beiträge
- 11.692
- Reaktionspunkte
- 4.077
Code:
find . -type f -print0 | xargs -0 md5 -r >/tmp/MD5SUM && mv /tmp/MD5SUM .
Code:
find . -type f ! -path "./MD5SUM" -print0 | xargs -0 md5 -r >MD5SUMWer sich mehr mit checksums beschäftigen will, sollte besser gleich zu hashdeep greifen.
Ich sichere mein System immer per TimeMachine.
AHT geht bei diesem MBP leider nicht. Welches Linux-System nutzt du? Und mit welchem Test? Per bootfähigem USB-Stick, richtig?!
Danke für Deine Hilfe!
Per USB Stick, Distro ist eigentlich egal, geht zB auch mit Ubuntu. Schau mal hier: http://www.dirk-hoeschen.de/Fundgrube_54_Defekte-Festplatten-analysieren-mit-smartctl.html
Ich nehme gparted live (http://gparted.org/livecd.php), das ist nur ca. 200 MB groß und hat sowohl smartctl als auch badblocks dabei.
Ich habe bei HFS+ Formatierten Festplatten auch super Erfahrungen mit DiskWarrior gemacht (das hilft natürlich nur, wenn die Platte ok aber das Dateisystem kaputt ist). Aber ob das bei neuen OS X Versionen auch noch gut ist, weiß ich nicht (aber das FS hat sich ja eigentlich nicht geändert, oder?). Und es kostet halt ca 100- Euro...
Hi rueueka!
Danke für den Tipp!
Ich bin gerade auf der Seite von gparted.
Welche Version genau sollte ich da nehmen?
Schon die "amd64"? oder eher die "i686-PAE"?
Jetzt habe ich mir die GParted-Distri auf nem Stick angelegt.
Seltsamerweise bootet der Stick bei meinem MBP nicht, genauer gesagt bricht er immer an einer bestimmten Stelle ab. Zu sehen auf dem Screenshot!
Schon seltsam, oder?!
Auf nem anderen MBP bootet der Stick einwandfrei. Ich werde dort dann mal die Festplatte via USB ranhängen...
Seltsamerweise bootet der Stick bei meinem MBP nicht, genauer gesagt bricht er immer an einer bestimmten Stelle ab. Zu sehen auf dem Screenshot!
Schon seltsam, oder?!
Auf nem anderen MBP bootet der Stick einwandfrei. Ich werde dort dann mal die Festplatte via USB ranhängen...
Anhänge
Genau diesen Befehl habe ich jetzt probiert (Festplatte hängt via USB an einem anderen MacBook):
Doch egal ob ich
Code:
find . -type f ! -path "./MD5SUM" -print0 | xargs -0 md5 -r >MD5SUM
Code:
sudo find . -type f ! -path "./MD5SUM" -print0 | xargs -0 md5 -r >MD5SUM
Code:
md5: ./.file: Permission denied
md5: ./.Spotlight-V100/Store-V2/71505845-9FBB-4570-BCD3-CC2EBBEF2593/store.updates: Permission denied
md5: ./.Spotlight-V100/Store-V2/E9BF67B7-153D-419E-8290-61EB7AD21200/store.updates: Permission deniedHi Olivetti,
vielen Dank, so scheint es zu funktionieren. Zumindest erhalte ich keine Fehlermeldung und im aktuellen Verzeichnis wird eine MD5SUM-Datei erstellt.
Nun noch zwei Fragen:
1. Woran erkenne ich, dass der Vorgang abgeschlossen ist?
2. Wenn der Befehl ohne Fehlermeldungen abschließt - was er aktuell im Versuchsverzeichnis (enthält nur wenige Dateien) - , bedeutet das dann, dass die Dateien keinen I/O-Fehler aufweisen?