yaVDR 0.4 hat schon 2x die NTFS-Platte gelöscht

dertede · 8. Januar 2013

Hallo,

ich bin hier grad am verzweifeln. Ich habe mir ein paar Videodateien (>2GB) bei einem Freund auf Festplatte (NTFS) kopiert. Diese habe ich dann per USB an meinen yaVDR 0.4 angeschlossen und per XBMC eine Datei geschaut.

Dann wollte ich einen Tag später wieder auf die Dateien zugreifen. Ich die Platte wieder angeschlossen und .... ... es passierte nichts. Weder unter MPlayer noch unter XBMC war das Laufwerk auffindbar.

Unter Windows will er die Platte gleich formatieren (ungültiges Dateisystem). Ich habe ein paar Recovery bzw Undelete-Tools ausprobiert, aber nichts gefunden.

Das Ganze ist nun 2x passiert.

Im Syslog sehe ich folgendes (gekürzt):

Code

Jan  8 20:14:33 vdr040 kernel: [108589.530092] usb 2-1: new high speed USB device using ehci_hcd and address 7
Jan  8 20:14:33 vdr040 kernel: [108589.683986] scsi13 : usb-storage 2-1:1.0
Jan  8 20:14:34 vdr040 kernel: [108590.682508] scsi 13:0:0:0: Direct-Access        Mass  Storage Device        PQ: 0 ANSI: 0
Jan  8 20:14:34 vdr040 kernel: [108590.684743] sd 13:0:0:0: Attached scsi generic sg6 type 0
Jan  8 20:14:34 vdr040 kernel: [108590.686522] sd 13:0:0:0: [sdg] 1250263726 512-byte logical blocks: (640 GB/596 GiB)
Jan  8 20:14:34 vdr040 kernel: [108590.687365] sd 13:0:0:0: [sdg] Write Protect is off
Jan  8 20:14:34 vdr040 kernel: [108590.687380] sd 13:0:0:0: [sdg] Mode Sense: 03 00 00 00
Jan  8 20:14:34 vdr040 kernel: [108590.687391] sd 13:0:0:0: [sdg] Assuming drive cache: write through
Jan  8 20:14:34 vdr040 kernel: [108590.691394] sd 13:0:0:0: [sdg] Assuming drive cache: write through
Jan  8 20:14:34 vdr040 kernel: [108590.724959]  sdg: sdg1
Jan  8 20:14:34 vdr040 kernel: [108590.728430] sd 13:0:0:0: [sdg] Assuming drive cache: write through
Jan  8 20:14:34 vdr040 kernel: [108590.728453] sd 13:0:0:0: [sdg] Attached SCSI disk
Jan  8 20:14:41 vdr040 kernel: [108597.748867] saa7146 (1) vpeirq: used 5 times >80% of buffer (65612 bytes now)
Jan  8 20:14:43 vdr040 kernel: [108599.160088] usb 2-1: reset high speed USB device using ehci_hcd and address 7

Alles anzeigen

Was anderes habe ich nicht gefunden. cat /proc/partitions findet ganz normal die Platte.

Wisst Ihr, woran das liegt? Und falls ja, wie bekomme ich die Daten wieder?

verzweifelte Grüße!

Keine_Ahnung · 8. Januar 2013

Was sagt denn parted dazu?
HDD anstecken, per "dmesg" schauen welches Device sie hat und dann "parted /dev/<device>", dann "p".

Und nein, normal ist das nicht Das wird irgenein sehr seltsamer Fehler sein.

cu

dertede · 8. Januar 2013

Hi,

parted unterstützt aber kein NTFS oder? p gibt es nicht, und check 1 meckert, dass es kein NTFS unterstützt.

"p" sagt mir, dass Du evtl fdisk meinst:

Code

hdvdr@vdr040:~$ sudo fdisk /dev/sdf


WARNING: DOS-compatible mode is deprecated. It's strongly recommended to
         switch off the mode (command 'c') and change display units to
         sectors (command 'u').


Befehl (m für Hilfe): p


Platte /dev/sdf: 640.1 GByte, 640135027712 Byte
53 Köpfe, 36 Sektoren/Spur, 655274 Zylinder
Einheiten = Zylinder von 1908 × 512 = 976896 Bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x205e4508


   Gerät  boot.     Anfang        Ende     Blöcke   Id  System
/dev/sdf1   *           2      655274   625129472    7  HPFS/NTFS


Befehl (m für Hilfe):

Alles anzeigen

Da sieht alles gut aus. Aber die Platte ist halt ratzeputzeleer

Keine_Ahnung · 8. Januar 2013

Zitat von dertede

parted unterstützt aber kein NTFS oder? p gibt es nicht, und check 1 meckert, dass es kein NTFS unterstützt.

"p" sagt mir, dass Du evtl fdisk meinst:

Doch, ich meinte schon parted, und bei mir geht "p" (habs vorher extra probiert).

Aber egal, es ging ja nur darum zu sehen ob da ne Partitionstabelle drauf ist.

Also ist das Dateisystem richtig kaputt, kenne ich von NTFS gar nicht, das ist extrem robust.
Wird mit sync oder mit async gemountet? Evtl. hat das mit dem sauberen Abmelden nicht geklappt?

cu

dertede · 8. Januar 2013

Naja, ich habe die Platte leider schon an so ein Windows Recoverytool angeschlossen, vorher hat er die Partition nicht gefunden (zumindestens nicht unter Windows)

Keine_Ahnung · 8. Januar 2013

Zitat von dertede

Naja, ich habe die Platte leider schon an so ein Windows Recoverytool angeschlossen, vorher hat er die Partition nicht gefunden (zumindestens nicht unter Windows)

Naja, dann würde das ja bedeuten das der Bootsektor überschrieben wurde.

Da wäre nen "hexdump -n 512 /dev/<device>" interesannt gewesen.

cu

zochi · 9. Januar 2013

doppelt

zochi · 9. Januar 2013

Zitat von zochi

[quote='dertede','index.php?page=Thread&postID=1118084#post1118084']Naja, ich habe die Platte leider schon an so ein Windows Recoverytool angeschlossen, vorher hat er die Partition nicht gefunden (zumindestens nicht unter Windows)

Schau mal nach, was für ein Chip in dem USB adapther drin ist.
Evtl. hilft schon mal ProdID:VendorID aus dmesg nach google zu gehen. Ansonsten musst Du mal das USB Gehäuse öffnen
und auf der Platine schauen, welcher chip dadrin ist. Es gab mal welche, die Probleme machten.
Leider sagst Du nicht welches USB-Gehäuse und welche Platte das ist. Wenn 2,5" ohne eigenes Netzteil, könnte die Stromversorgung via USB das Problem sein. Halt das frisch angeschlossene Laufwerk mal ans Ohr, ob die Platte ständig hoch und runter läuft oder obe Du das konstante Sirren hörst. Wenn die Platte immer wieder startet musst Du ein Y-Kabel nehmen und eine 2. USB Buchse benutzen. Ectl. hilft ein Hub mit eigenem Netzteil. Logo das Du die 2,5"-Platten nur mit den rel. kurzen und dicken original USB-Kabeln ohne Verlängerungen anschliessen solltest.

dertede · 15. Januar 2013

Das ist sehr komisch mit der Platte. Es ist eine Samsung HM641JI 640GB, das Gehäuse ist ein Sharkoon Quickstore Portable, den Chip kann ich von aussen nicht sehen und Linux hab ich grad nicht zur Hand :-). Die Platte hat tatsächlich nur die Spannung per einem USB-Kabel, allerdings fährt sie ordnungsgemäß hoch, zumindestens akustisch

Wie dem auch sei, der Fehler ist mittlerweile nicht nur bei yaVDR 0.4 aufgetreten, sondern auch an meiner Dockstar mit Debian Squeeze installiert. Alles sehr seltsam, immerhin hab ich auf dieser Platte keine nicht-redundanten Daten mehr drauf :-).

Keine_Ahnung · 15. Januar 2013

Ich hatte auch schonmal nen USB SD Kartenleser der hin und wieder Bits (an zufälligen Positionen) bei der Übertragung gekippt hat. Das konnte man nach der Übertragung einer grossen Mege Fotos mit einem Dateivergleich feststellen. Im Normalbetrieb ist es nicht aufgefallen da gekippte Bits bei JPG meist nicht auffallen.

Evtl. ist es ja auch hier der Fall? Und gekippte Bits bei NTFS in den Verwaltugsinformationen machen das Dateisystem vermutlich zielsicher kaputt.

cu

steffen_b · 15. Januar 2013

Nur um es nochmal zusammenzufassen, bevor aus dem Threadtitel ein "Urban Myth" wird:

Weder Ubuntu noch yavdr löschen NTFS formatierte Platten. Auch nicht wenn man yavdr "verkehrt" (nicht den Vorstellungen der Macher entsprechend) benutzt

dertede · 15. Januar 2013

gut, dass Du noch einmal darauf hinweist, wobei ich das nicht so verstanden habe. Ich habe mich jetzt darauf eingestellt und werde am Wochenende mal das Gehäuse der Platte tauschen und hoffen, dass der Fehler dann verschwunden ist. Was nur komisch ist, dass unter Windows die Platte wunderbar funktioniert - naja, ist halt ein Microsoft-Dateisystem :-|

steffen_b · 15. Januar 2013

Eventuell führt ein Hardwaredefekt schneller zum Verlust des Dateisystems wenn das Dateisystem nur durch auf Reverse Engineering basierenden Wissen entstanden ist. Das sind aber Feinheiten - letztenendes solltest du deine Hardware fixen, dann läufts auch wieder Auch ich benutze einige portable Platten mit NTFS und habe seit einigen Jahren keine Probleme damit.

zochi · 18. Januar 2013

Diese Platte braucht 2,5W. Das kann funktionieren, musss aber nicht da die USB2.0 Buchse max. 2,5W liefern kann.
Das sie hochläuft muss nicht heissen, das sie durchläuft, denn die Kopfbewegung kostet ja zusätzlichen Strom.
Du könntest mit "smartctl" mal nachsehen, ob sich während des Kopierens, der Start-Stop und Landecounter ändert.

Was immer wieder übersehen wird: Die USB Kabel sind wichtig. Hier sollte das Kabel nicht "länger" als 30cm sein und mit rel.viel Kupfer, dick. Auf dem Kabel sollte was von "High speed USB 2.0" stehen (so in längst Richtung ganz klein eingeprägt) und es sollte aus 2 dünnen und 2 dicken Drähten (2 AGW Werte) bestehen.
Die USB-Kontroler merken, wenn Datenfehler auftreten und korrigiert diese. Leider weiss ich nicht, wo man auslesen könnte, wieoft die Korrektur ausgelöst hat, so das viele Schrott-Kabel unbemerkt unterwegs sind. "Funktioniert doch". Klar, wenn man jedes Paket 50000 mal wiederholt (BTST) ehe es ohne Fehler angekommen ist, "funktioniert" es...

Letztlich kann auch noch ein RAM Problem voriegen oder ein kaputter Treiber, der immermal wieder irgendwohin schreibt, und dabei die Dateistrukturen im RAM ändert. Das könnte erklären, warum es unter Windows geht aber unter Linux nicht:
Beim Linux werden andere Speicherbereiche genutzt. Allerdings würden dann auch andere Instabilitäten aufgetreten sein.

DocViper · 21. Januar 2013

Möglicherweise ist die Ursache jetzt erkannt:

http://www.heise.de/open/artik…t-ignorieren-1780899.html

http://www.heise.de/open/artik…ehrdet-Daten-1780057.html

yaVDR 0.4 hat schon 2x die NTFS-Platte gelöscht

Jetzt mitmachen!

Teilen

Benutzer online in diesem Thema