Externe 4TB Intenso HDD nach Systemabsturz mit btrfs Fehler

timo08 · August 12, 2016, 10:22am

Hallo,

nach dem dist-upgrade von opneSUSE 13.1 auf Leap 42.1 lief soweit alles super, bis ich meine externe 4TB Platte von Intenso angeschlossen habe.
Kurz darauf kam es zu einem Systemabsturz (keine Ahnung ob es etwas mit der Festplatte zu tun hatte) und danach konnte ich leider nicht mehr auf meine externe Festplatte zugreifen.
Kam mir schon etwas komisch vor, dass ich die Festplatte angeschlossen habe, die Geräteüberwachung jedoch keinen Finger gerührt hat.
Also Gparted gestartet und es kam eine Fehlerinformation, dass wohl irgendetwas mit der GPT nicht stimmt. Selbst Gparted konnte das nicht reparieren und man hat ja die gute alte Konsole, aber …:’(

**Laptop:/home/timo #** btrfs check --repair /dev/sdb    
enabling repair mode
No valid Btrfs found on /dev/sdb
Couldn't open file system

Habe bereits einige Foren durchsucht und auch so einige Lösungsvorschläge gefunden, hat jedoch bisher nichts geholfen.
Es kommt jedes mal oben stehende Fehlermeldung, auch wenn ich /dev/sdb1 untersuchen lasse, wo zuvor die Partition lag.

Hat vielleicht jemand eine Idee was man da machen könnte?

Vielen Dank schonmal

wolfi323 · August 12, 2016, 12:14pm

Das kann nicht funktionieren.
/dev/sdb ist die komplette Festplatte, ein Filesystem ist aber normalerweise in einer Partition.

Es kommt jedes mal oben stehende Fehlermeldung, auch wenn ich /dev/sdb1 untersuchen lasse, wo zuvor die Partition lag.

Die gleiche Fehlermeldung? Oder eine andere?

Und ist die (externe) Festplatte überhaupt mit btrfs formatiert?
Probier mal einfach nur “fsck /dev/sdb1”.

Ansonsten: vielleicht hilft testdisk weiter?
Wenn du zumindest die Daten retten kannst, wäre ja eine Neuformatierung kein Problem.

timo08 · August 12, 2016, 12:43pm

Bekomme folgende Ausgabe:

**Laptop:/home/timo #** fsck /dev/sdb1
fsck from util-linux 2.25
e2fsck 1.42.11 (09-Jul-2014)
ext2fs_open2: Bad magic number in super-block
fsck.ext2: Superblock invalid, trying backup blocks...
fsck.ext2: Bad magic number in super-block while trying to open /dev/sdb1

The superblock could not be read or does not describe a valid ext2/ext3/ext4
filesystem.  If the device is valid and it really contains an ext2/ext3/ext4
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 or
    e2fsck -b 32768 <device>

Ich hab die Festplatte ja schon länger genutzt und das btrfs war bisher eigentlich immer recht stabil dabei.
Das Problem ist, dass ich kein anderes Speichermedium habe, das etwa 2TB Daten fassen könnte. Deswegen hoffe ich immer noch auf eine Reparaturmöglichkeit.
Geht denn da nicht noch mehr kaputt, mit “e2fsck -b 8193”, da das Dateisystem ja btrfs war und nicht ext?

wolfi323 · August 12, 2016, 12:55pm

Ok, also scheinbar kein btrfs, sonden ext2/ext3/ext4.
Also kein Wunder dass btrfs --check kein Dateisystem findet…

Geht denn da nicht noch mehr kaputt, mit “e2fsck -b 8193”, da das Dateisystem ja btrfs war und nicht ext?

Mehr kaputt gehen wird nicht, denke ich, eher wird e2fsck abbrechen.

8193 ist aber nur ein Beispiel, und trifft nicht unbedingt auf deine Festplatte zu.

Andererseits: du bist sicher dass die Festplatte btrfs benutzte? Hast du sie selbst formatiert?
Dann ist wohl leider nicht viel zu machen, wenn das jetzt als ext erkannt wird ist einiges komplett überschrieben worden.
Was sagt denn das Kommando “blkid”?

testdisk führt die Reparaturen in-place, also wäre es vielleicht einen Versuch wert (ist in der Distribution enthalten, einfach das Paket “testdisk” installieren). Sh. http://www.cgsecurity.org/wiki/TestDisk_DE
Allerdings wird scheinbar btrfs noch nicht unterstützt…

Akoellh · August 12, 2016, 12:52pm

Am Fri, 12 Aug 2016 10:46:02 GMT
schrieb timo08 <timo08@no-mx.forums.microfocus.com>:

> Bekomme folgende Ausgabe:
>
> Code:
> --------------------
> Laptop:/home/timo # fsck /dev/sdb1
> fsck from util-linux 2.25
> e2fsck 1.42.11 (09-Jul-2014)
> ext2fs_open2: Bad magic number in super-block
> fsck.ext2: Superblock invalid, trying backup blocks…
> fsck.ext2: Bad magic number in super-block while trying to open /dev/sdb1
>
> The superblock could not be read or does not describe a valid ext2/ext3/ext4
> filesystem. If the device is valid and it really contains an ext2/ext3/ext4
> filesystem (and not swap or ufs or something else), then the superblock
> is corrupt, and you might try running e2fsck with an alternate superblock:
> e2fsck -b 8193 <device>
> or
> e2fsck -b 32768 <device>
>
> --------------------
>
>
> Ich hab die Festplatte ja schon länger genutzt und das btrfs war bisher
> eigentlich immer recht stabil dabei.
> Das Problem ist, dass ich kein anderes Speichermedium habe, das etwa 2TB
> Daten fassen könnte. Deswegen hoffe ich immer noch auf eine
> Reparaturmöglichkeit.
> Geht denn da nicht noch mehr kaputt, mit “e2fsck -b 8193”, da das
> Dateisystem ja btrfs war und nicht ext?
>
>

Paket btrfsprogs installiert, binary “fsck.btrfs” vorhanden?

Mit e2fsck machst Du bestenfalls was kaputt.

AK

–
Never attribute to malice that which can be adequately explained by stupidity.
(R.J. Hanlon)

Akoellh · August 12, 2016, 1:02pm

Am Fri, 12 Aug 2016 10:52:03 GMT
schrieb AK <Akoellh@no-mx.forums.microfocus.com>:

>
>
> Paket btrfsprogs installiert, binary “fsck.btrfs” vorhanden?
>
> Mit e2fsck machst Du bestenfalls was kaputt.
>
> AK
>

Ops, da hatte ich was überlesen, streichen Sie die obige Bemerkung,

Die Ausgabe von

file /dev/sdb1

als root wäre aber auf jeden Fall interessant.

AFAIK probiert fsck der Reihe nach die verschiedenen ihm bekannten Dateisystem
durch und fällt am Schluss auf e2fsck zurück, falls es nichts “passendes”
findet.

Sieht also nicht wirklich gut aus, denn entweder ist auf sdb1 wirklich ein
ext2/3/4 oder die Partition ist nahe an Schleifpaste.

AK

–
Never attribute to malice that which can be adequately explained by stupidity.
(R.J. Hanlon)

Akoellh · August 12, 2016, 1:05pm

Am Fri, 12 Aug 2016 11:02:22 GMT
schrieb AK <Akoellh@no-mx.forums.microfocus.com>:

> file /dev/sdb1
>
> als root wäre aber auf jeden Fall interessant.
>

Oh Mann, heute ist aber echt der Wurm drin.

Wenn schon, dann natürlich so:

file -sk /dev/sdb1

AK

–
Never attribute to malice that which can be adequately explained by stupidity.
(R.J. Hanlon)

timo08 · August 12, 2016, 1:18pm

Alles als root ausgeführt:

btrfsprogs ist installiert und fsck.bt lässt sich nach fsck.btrfs erweitern. War definitiv btrfs, habs selbst angelegt.
blkid führt die sdb erst gar nicht auf, soweit ich das erkennen konnte:

**Laptop:/home/timo #** blkid
/dev/sda2: LABEL="win7" UUID="55447F680E8200EF" TYPE="ntfs" PARTUUID="14a45bd6-1cf0-4738-8dcd-e53e2ff6d2fe"  
/dev/sda3: UUID="800f67b9-fc4b-4bf3-904a-105f7a9cc909" TYPE="swap" PARTUUID="8d996aa0-9108-4c7e-8d66-ee60203279ed"  
/dev/sda4: LABEL="kubuntu" UUID="d928fa43-0c4c-487d-bc57-88dcec301fd7" TYPE="ext4" PARTUUID="3725c8e1-e35d-4dcf-8947-6603f307
d64c"  
/dev/sda5: LABEL="opensuse" UUID="148d608b-7cfc-473a-b180-6ffc4b7887be" TYPE="ext4" PTTYPE="dos" PARTUUID="516a8bda-7b90-4c52
-9401-5b320bf089ad"  
/dev/sda6: UUID="8ad7ae72-7d2e-4ccc-8c70-49a339debd7d" TYPE="ext4" PARTUUID="005b5851-f78e-43b3-978c-f8a981a604cb"  
/dev/sda7: LABEL="bootmenue_opensuse" UUID="1416a596-473e-412c-a25e-45b69dd20972" UUID_SUB="69afa2cb-a301-4f4f-ace5-199a24b8d
13b" TYPE="btrfs" PTTYPE="dos" PARTUUID="7a22a927-6a81-46c6-b93a-449796787eb4"  
/dev/sda8: LABEL="Zusatzspeicher" UUID="bf4c4509-db37-46f7-9e9d-5d180ecc0999" TYPE="ext4" PARTUUID="aa3e777c-77ca-4eb9-a0ef-a
825f9f1e07a"  
/dev/sda1: PARTLABEL="primary" PARTUUID="7b51772e-3260-4e1b-9a9a-99c2321a634d"

**Laptop:/home/timo #** file -sk /dev/sdb1
/dev/sdb1: GPT data structure (nonstandard: at LBA 0), version 1.0, GUID: e6893923-5730-40da-a41f-88173f191bea, disk size: 97
6754646 sectors (sector size unknown)

Könnte man mit mkfs.btrfs was erreichen? Testdisk ist installiert, aber ich habe auch keine btrfs Unterstützung gefunden.

Akoellh · August 12, 2016, 2:43pm

Am Fri, 12 Aug 2016 11:26:01 GMT
schrieb timo08 <timo08@no-mx.forums.microfocus.com>:

> Alles als root ausgeführt:
>
> btrfsprogs ist installiert und fsck.bt lässt sich nach fsck.btrfs
> erweitern. War definitiv btrfs, habs selbst angelegt.
> blkid führt die sdb erst gar nicht auf, soweit ich das erkennen konnte:
>
> Code:
> --------------------
> Laptop:/home/timo # blkid
> /dev/sda2: LABEL=“win7” UUID=“55447F680E8200EF” TYPE=“ntfs”
> PARTUUID=“14a45bd6-1cf0-4738-8dcd-e53e2ff6d2fe” /dev/sda3:
> UUID=“800f67b9-fc4b-4bf3-904a-105f7a9cc909” TYPE=“swap”
> PARTUUID=“8d996aa0-9108-4c7e-8d66-ee60203279ed” /dev/sda4: LABEL=“kubuntu”
> UUID=“d928fa43-0c4c-487d-bc57-88dcec301fd7” TYPE=“ext4”
> PARTUUID=“3725c8e1-e35d-4dcf-8947-6603f307 d64c” /dev/sda5: LABEL=“opensuse”
> UUID=“148d608b-7cfc-473a-b180-6ffc4b7887be” TYPE=“ext4” PTTYPE=“dos”
> PARTUUID=“516a8bda-7b90-4c52 -9401-5b320bf089ad” /dev/sda6:
> UUID=“8ad7ae72-7d2e-4ccc-8c70-49a339debd7d” TYPE=“ext4”
> PARTUUID=“005b5851-f78e-43b3-978c-f8a981a604cb” /dev/sda7:
> LABEL=“bootmenue_opensuse” UUID=“1416a596-473e-412c-a25e-45b69dd20972”
> UUID_SUB=“69afa2cb-a301-4f4f-ace5-199a24b8d 13b” TYPE=“btrfs” PTTYPE=“dos”
> PARTUUID=“7a22a927-6a81-46c6-b93a-449796787eb4” /dev/sda8:
> LABEL=“Zusatzspeicher” UUID=“bf4c4509-db37-46f7-9e9d-5d180ecc0999”
> TYPE=“ext4” PARTUUID=“aa3e777c-77ca-4eb9-a0ef-a 825f9f1e07a” /dev/sda1:
> PARTLABEL=“primary” PARTUUID=“7b51772e-3260-4e1b-9a9a-99c2321a634d”
> --------------------

Das ist schlecht.

> Code:
> --------------------
> Laptop:/home/timo # file -sk /dev/sdb1
> /dev/sdb1: GPT data structure (nonstandard: at LBA 0), version 1.0, GUID:
> e6893923-5730-40da-a41f-88173f191bea, disk size: 97 6754646 sectors (sector
> size unknown)
> --------------------

Nun muss ich vorsichtig sein, da ich selbst kein btrfs einsetze, aber so auf
die Schnelle sieht das bei mir so aus:

dd if=/dev/zero of=/tmp/foobar bs=1M count=512
512+0 Datensätze ein
512+0 Datensätze aus
536870912 Bytes (537 MB) kopiert, 2,14759 s, 250 MB/s

mkfs.btrfs /tmp/foobar

– snip — (Ausgabe gekürzt)

und dann

file -sk /tmp/foobar

/tmp/foobar: BTRFS Filesystem sectorsize 4096, nodesize 4096, leafsize 409

Deine Ausgabe erkennt nur “das ist wohl ne Partition aber mehr kann ich nicht
sagen”.

Ich weiß allerdings nicht in wie fern sich da Dateien von Blockdevices
unterscheiden, wenn sie BTRFS formatiert sind (alle anderen Dateisysteme, die
ich verwende zeigen keinen nennenswerten Unterschied) und ich würde vermuten,
zumindest das Stichwort “btrfs” sollte auftauchen, was es bei Dir nicht tut.

Ich frage mich allerdings auch gerade, wieso blkid gar nix ausgibt, was sagt
denn (als root)?

fdisk -l /dev/sdb

(sofern sdb die externe ist, ansonsten anpassen)

Zusätzlich sollte man sich auch Folgendes ansehen:

Platte entfernen (USB-Stecker ziehen)
Im Terminal

dmesg --follow

Platte anstöpseln und die hinzukommenden Ausgaben ansehen

Ich befürchte da ist mehr als nur ein Dateisystem im Eimer

>
> Könnte man mit mkfs.btrfs was erreichen?

Möglicherweise ja, aber wahrscheinlich das Ungewollte (= Zerstörung dessen, was
vielleicht noch da ist).

> Testdisk ist installiert, aber
> ich habe auch keine btrfs Unterstützung gefunden.

Das dürfte das nächste Problem werden, falls testdisk hier überhaupt was
ausrichten kann.

AK

–
Never attribute to malice that which can be adequately explained by stupidity.
(R.J. Hanlon)

timo08 · August 12, 2016, 3:02pm

**Laptop:/home/timo #** fdisk -l /dev/sdb

Disk /dev/sdb: 3.7 TiB, 4000787030016 bytes, 976754646 sectors
Units: sectors of 1 * 4096 = 4096 bytes
Sector size (logical/physical): 4096 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 268431360 bytes
Disklabel type: dos
Disk identifier: 0x083ac1f8

**Device     Boot Start       End   Sectors  Size Id Type**
/dev/sdb1           1 976754645 976754645  3.7T 63 GNU HURD or SysV

Habe jetzt die Platte entfernt, gebe “dmesg --follow” ein und stecke die Platte anschließend wieder an.
Hab etwa 2700 Zeilen ausgegeben bekommen.
Der untere Teil, der vermutlich wichtig ist:

[16110.335816] sd 4:0:0:0: [sdb] tag#0 data cmplt err -71 uas-tag 1 inflight: CMD  
[16110.335827] sd 4:0:0:0: [sdb] tag#0 CDB: Read(10) 28 00 24 1c 4b e0 00 00 01 00
[16110.660874] usb 4-2: USB disconnect, device number 4
[16110.661192] usb 4-2: stat urb: status -108
[16110.661217] sd 4:0:0:0: [sdb] tag#0 uas_zap_pending 0 uas-tag 1 inflight: CMD 
[16110.661225] sd 4:0:0:0: [sdb] tag#0 CDB: Read(10) 28 00 24 1c 4b e0 00 00 01 00
[16110.661283] sd 4:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK
[16110.661288] sd 4:0:0:0: [sdb] tag#0 CDB: Read(10) 28 00 24 1c 4b e0 00 00 01 00
[16110.661293] blk_update_request: I/O error, dev sdb, sector 4846673664
[16113.121903] sd 4:0:0:0: [sdb] Synchronizing SCSI cache
[16113.240784] sd 4:0:0:0: [sdb] Synchronize Cache(10) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK
[16194.366265] usb 4-2: new SuperSpeed USB device number 5 using xhci_hcd
[16194.388433] usb 4-2: New USB device found, idVendor=174c, idProduct=55aa
[16194.388441] usb 4-2: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[16194.388446] usb 4-2: Product: USB 3.0 Device
[16194.388450] usb 4-2: Manufacturer: Intenso
[16194.388453] usb 4-2: SerialNumber: 90300000000000001C46
[16194.392697] scsi host5: uas
[16194.393175] scsi 5:0:0:0: Direct-Access     ASMT     2105             0    PQ: 0 ANSI: 6
[16194.393837] sd 5:0:0:0: Attached scsi generic sg2 type 0
[16194.394755] sd 5:0:0:0: [sdb] 976754646 4096-byte logical blocks: (4.00 TB/3.64 TiB)
[16194.395201] sd 5:0:0:0: [sdb] Write Protect is off
[16194.395208] sd 5:0:0:0: [sdb] Mode Sense: 43 00 00 00
[16194.395385] sd 5:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[16194.425250]  sdb: sdb1
[16194.426655] sd 5:0:0:0: [sdb] Attached SCSI disk

Den gesamten Code habe ich in einer Datei gespeichert.
https://binsky.org/dmesg-ausgabe.txt
Die Datei endet damit, dass die Festplatte angesteckt habe.

Folgendes erscheint zusätzlich, wenn ich die Platte wieder abziehe:


[16224.600666] usb 4-2: USB disconnect, device number 5
[16224.601721] sd 5:0:0:0: [sdb] Synchronizing SCSI cache                                                                                                                                        
[16224.724922] sd 5:0:0:0: [sdb] Synchronize Cache(10) failed: Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK

Hoffe da sind gute Nachrichten dabei

Akoellh · August 12, 2016, 5:28pm

Am Fri, 12 Aug 2016 13:06:01 GMT
schrieb timo08 <timo08@no-mx.forums.microfocus.com>:

> Code:
> --------------------
> Laptop:/home/timo # fdisk -l /dev/sdb
>
> Disk /dev/sdb: 3.7 TiB, 4000787030016 bytes, 976754646 sectors
> Units: sectors of 1 * 4096 = 4096 bytes
> Sector size (logical/physical): 4096 bytes / 4096 bytes
> I/O size (minimum/optimal): 4096 bytes / 268431360 bytes
> Disklabel type: dos
> Disk identifier: 0x083ac1f8
>
> Device Boot Start End Sectors Size Id Type
> /dev/sdb1 1 976754645 976754645 3.7T 63 GNU HURD or SysV
>
> --------------------
>

Ach ja, GPT und fdisk, daran hatte ich nicht gedacht, das ging zumindest bis
vor kurzem nicht zwingend gut zusammen (kann aber mittlerweile besser sein).

Statt dessen eher ein

parted /dev/sdb print

als root zeigt vielleicht was Aussagekräftigeres an.

>
> Habe jetzt die Platte entfernt, gebe “dmesg --follow” ein und stecke die
> Platte anschließend wieder an.
> Hab etwa 2700 Zeilen ausgegeben bekommen.
> Der untere Teil, der vermutlich wichtig ist:
>
> Code:
> --------------------
> [16110.335816] sd 4:0:0:0: [sdb] tag#0 data cmplt err -71 uas-tag 1
> inflight: CMD [16110.335827] sd 4:0:0:0: [sdb] tag#0 CDB: Read(10) 28 00 24
> 1c 4b e0 00 00 01 00 [16110.660874] usb 4-2: USB disconnect, device number 4
> [16110.661192] usb 4-2: stat urb: status -108
> [16110.661217] sd 4:0:0:0: [sdb] tag#0 uas_zap_pending 0 uas-tag 1
> inflight: CMD [16110.661225] sd 4:0:0:0: [sdb] tag#0 CDB: Read(10) 28 00 24
> 1c 4b e0 00 00 01 00 [16110.661283] sd 4:0:0:0: [sdb] tag#0 FAILED Result:
> hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK [16110.661288] sd 4:0:0:0: [sdb]
> tag#0 CDB: Read(10) 28 00 24 1c 4b e0 00 00 01 00 [16110.661293]

Hm. uas funkt da also auch noch rein, diese Fehlermeldungen kann ich jetzt
nicht definitiv beurteilen, möglicherweise nicht wirklich schlimm (siehe unten).

> blk_update_request: I/O error, dev sdb, sector 4846673664 [16113.121903] sd

das hier sieht definitiv nicht gut aus.

>
> Den gesamten Code habe ich in einer Datei gespeichert.
> https://binsky.org/dmesg-ausgabe.txt
> Die Datei endet damit, dass die Festplatte angesteckt habe.
>
> Folgendes erscheint zusätzlich, wenn ich die Platte wieder abziehe:
>
> Code:
> --------------------
>
> [16224.600666] usb 4-2: USB disconnect, device number 5
> [16224.601721] sd 5:0:0:0: [sdb] Synchronizing SCSI
> cache [16224.724922] sd 5:0:0:0: [sdb] Synchronize Cache(10) failed: Result:
> hostbyte=DID_ERROR driverbyte=DRIVER_OK
> --------------------
>
> Hoffe da sind gute Nachrichten dabei
>
>

Eher das Gegenteil, bei dem Log wird einem ja übel, da kotzt sich so Einiges
(mehrfach) aus, allerdings hat das ganze Zeug am Anfang nichts mit sdbX zu tun.

[10569.125747] Call Trace:
[10569.125759] <ffffffff810055cc>] dump_trace+0x8c/0x340
[10569.125765] <ffffffff8100597c>] show_stack_log_lvl+0xfc/0x1a0
[10569.125771] <ffffffff81006ec1>] show_stack+0x21/0x50
[10569.125777] <ffffffff8165f3d0>] dump_stack+0x5d/0x79
[10569.125783] <ffffffff811746de>] warn_alloc_failed+0xce/0x140
[10569.125789] <ffffffff81177b77>] __alloc_pages_nodemask+0x2e7/0xa10
[10569.125797] <ffffffff811c1043>] kmem_getpages+0x53/0x100
[10569.125802] <ffffffff811c27d5>] fallback_alloc+0x155/0x200
[10569.125808] <ffffffff811c4f29>] __kmalloc+0x239/0x4f0
[10569.125987] <ffffffffa1123553>] drm_alloc+0xc3/0x1a0 [fglrx]
[10569.126118] <ffffffffa1143375>] __alloc_memory_pcie+0x65/0x260 [fglrx]
[10569.126244] <ffffffffa11416be>] gal_alloc_gart_memory+0x3e/0xa0 [fglrx]
[10569.126372] <ffffffffa114bd11>] __mc_heap_alloc_memory+0xf1/0x1f0 [fglrx]
[10569.126500] <ffffffffa1146e24>] mc_heap_allocate_memory+0x74/0x130 [fglrx]
[10569.126626] <ffffffffa1139f14>] MCIL_AllocateMemoryInDescriptor+0x74/0xe0 [fglrx]
[10569.126790] <ffffffffa11f55cf>] _ZN2OS10gart_AllocEP7CMMPoolmmRm9_CMM_HEAP+0xef/0x1f0 [fglrx]
[10569.126945] <ffffffffa11cf526>] _ZN12CMMHeap_GART10expandHeapEmRmPv+0x76/0x100 [fglrx]
[10569.127098] <ffffffffa11ce6af>] _ZN7CMMHeap21allocateMorePoolSpaceEmPv+0x8f/0x1b0 [fglrx]
[10569.127250] <ffffffffa11cd55c>] _ZN14CMMHeapManager8allocMemEjmRK13CMM_ALIGNMENTP21MEMHEAP_ADDR_RESTRICTR14CMM_ALLOCATION+0x22c/0x2b0 [fglrx]
[10569.127413] <ffffffffa11ee13b>] _ZN3MSF10alloc_surfEP9CMMClientP9CMMDriverP21MEMHEAP_ADDR_RESTRICTjP16MSF_SURF_ATTRIBSP15_CMM_RETURNCODE+0x8b/0x670 [fglrx]
[10569.127573] <ffffffffa11e27c8>] Z18CMMAllocSurface_WAmP21_CMM_SURF_DESCRIPTOR_P18_CMM_SURF_INFO_WA+0x488/0xbe0 [fglrx]
[10569.127741] <ffffffffa11fdb23>] _Z17CMMAllocVirtual1DmP24_CMM_ALLOC_VIRTUAL_1D_INP25_CMM_ALLOC_VIRTUAL_1D_OUT+0x243/0x470 [fglrx]
[10569.127896] <ffffffffa11d4b8a>] Z8uCWDDEQCmjjPvjS+0xd4a/0x12c0 [fglrx]
[10569.128045] <ffffffffa11ca5ea>] CMMQS_uCWDDEQC+0xa/0x10 [fglrx]
[10569.128177] <ffffffffa115f25f>] firegl_cmmqs_CWDDE_32+0x36f/0x480 [fglrx]
[10569.128308] <ffffffffa115dace>] firegl_cmmqs_CWDDE32+0x8e/0x140 [fglrx]
[10569.128428] <ffffffffa112b8d4>] firegl_ioctl+0x1f4/0x260 [fglrx]
[10569.128547] <ffffffffa11191ae>] ip_firegl_unlocked_ioctl+0xe/0x20 [fglrx]
[10569.128554] <ffffffff811f1fcf>] do_vfs_ioctl+0x2ff/0x510
[10569.128573] <ffffffff811f2261>] SyS_ioctl+0x81/0xa0
[10569.128580] <ffffffff81665bb2>] system_call_fastpath+0x16/0x75
[10569.128589] <00007f8d2804bbc7>] 0x7f8d2804bbc7
[10569.128688] Mem-Info:

OK, fglrx (= proprietärer ATI Treiber) ist von ziemlich “fragwürdiger”
Qualität (der von Nvidia ist aber auch nicht viel besser), das muss nicht
zwingend was heissen, aber auch hier wieder:

[16110.661293] blk_update_request: I/O error, dev sdb, sector 4846673664

Das sieht nicht gut aus.

Du schreibst das Ganze wäre nach einem Systemabsturz passiert und diese ganzen
anderen Fehlermeldungen im Log legen zumindest den Verdacht nahe, dass auchdas
Hostsystem was abbekommen haben könnte. Probier das Ganze doch mal mit einem
externen System (Live-CD o.ä.) um diese Möglichkeit auszuschließen.

Ich bin da aber anhand der anderen Meldungen zur externen Festplatte nicht
wirklich optimistisch.

Zum Thema “möglicherweise sind nicht alle Meldungen zu sdb schlimm”.

Ich habe zufälligerweise (fast) die selbe externe Platte (2 statt 4TB aber
selber Controller, lass mich raten, großer deutscher Discounter mit “A”?) und
da sieht das so aus.

Anstöpseln:

[63729.648201] usb 1-1: new high-speed USB device number 11 using ehci-pci
[63729.782712] usb 1-1: New USB device found, idVendor=174c, idProduct=55aa
[63729.782730] usb 1-1: New USB device strings: Mfr=2, Product=3, SerialNumber=1
[63729.782739] usb 1-1: Product: USB 3.0 Device
[63729.782747] usb 1-1: Manufacturer: Intenso
[63729.782755] usb 1-1: SerialNumber: XXXXXXXXXXXXXXXXXXXXXXXXXXXX
[63729.786297] usb-storage 1-1:1.0: USB Mass Storage device detected
[63729.789635] usb-storage 1-1:1.0: Quirks match for vid 174c pid 55aa: 400000
[63729.789747] scsi host6: usb-storage 1-1:1.0
[63730.795284] scsi 6:0:0:0: Direct-Access Intenso USB 3.0 Device 0 PQ: 0 ANSI: 6
[63730.799183] sd 6:0:0:0: Attached scsi generic sg1 type 0
[63736.844878] sd 6:0:0:0: [sdb] 3907029168 512-byte logical blocks: (2.00 TB/1.82 TiB)
[63736.844896] sd 6:0:0:0: [sdb] 4096-byte physical blocks
[63736.846060] sd 6:0:0:0: [sdb] Write Protect is off
[63736.846072] sd 6:0:0:0: [sdb] Mode Sense: 43 00 00 00

—> [63736.847340] sd 6:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn’t support DPO or FUA <-------

[63736.920614] sdb: sdb1 sdb2 sdb3 < sdb5 sdb6 sdb7 >
[63736.927748] sd 6:0:0:0: [sdb] Attached SCSI disk

Abziehen:

[63743.135324] usb 1-1: USB disconnect, device number 11
[63743.147590] sd 6:0:0:0: [sdb] Synchronizing SCSI cache
—> [63743.147743] sd 6:0:0:0: [sdb] Synchronize Cache(10) failed: Result:hostbyte=DID_NO_CONNECT driverbyte=DRIVER_OK <—

Die Warnungen/Fehler, die bei Dir zusätzlich auftauchen sind also
wahrscheinlich ernst zu nehmen.

AK

–
Never attribute to malice that which can be adequately explained by stupidity.
(R.J. Hanlon)

timo08 · August 13, 2016, 10:48am

linux:/home/timo # parted /dev/sdb print
Warning: /dev/sdb contains GPT signatures, indicating that it has a GPT table.  However, it does not have a valid fake msdos partition table, as it should.  Perhaps it was corrupted --
possibly by a program that doesn't understand GPT partition tables.  Or perhaps you deleted the GPT table, and are now using an msdos partition table.  Is this a GPT partition table?
Yes/No? Yes                                                               
Warning: /dev/sdb contains GPT signatures, indicating that it has a GPT table.  However, it does not have a valid fake msdos partition table, as it should.  Perhaps it was corrupted --
possibly by a program that doesn't understand GPT partition tables.  Or perhaps you deleted the GPT table, and are now using an msdos partition table.  Is this a GPT partition table?
Yes/No? Yes                                                               
Model: ASMT 2105 (scsi)
Disk /dev/sdb: 4001GB
Sector size (logical/physical): 4096B/4096B
Partition Table: gpt_sync_mbr
Disk Flags: 

Number  Start   End     Size    File system  Name  Flags
 1      1049kB  4001GB  4001GB

Wieso auch immer hat mein eigentliches Syste die Festplatte jetzt nicht mal mehr unter /dev/sdX angezeigt.
Habe zum Glück noch ein anderes lauffähiges openSUSE 13.2 (privates Rettungssystem) von dem ich erstmal arbeite.
Auch wieder alles als root.
Das mit der GPT Tabelle scheint vielleicht ein Ansatz zu sein.
In folge dessen bin ich auf gdisk gestoßen. Hab allerdings keine Ahnung, wie es jetzt weiter geht:

linux:/home/timo # gdisk /dev/sdb
GPT fdisk (gdisk) version 0.8.10

Partition table scan:
  MBR: MBR only
  BSD: not present
  APM: not present
  GPT: present

Found valid MBR and GPT. Which do you want to use?
 1 - MBR
 2 - GPT
 3 - Create blank GPT

Your answer: 2
Using GPT and creating fresh protective MBR.

Command (? for help): ?
b       back up GPT data to a file
c       change a partition's name
d       delete a partition
i       show detailed information on a partition
l       list known partition types
n       add a new partition
o       create a new empty GUID partition table (GPT)
p       print the partition table
q       quit without saving changes
r       recovery and transformation options (experts only)
s       sort partitions
t       change a partition's type code
v       verify disk
w       write table to disk and exit
x       extra functionality (experts only)
?       print this menu

Command (? for help): p
Disk /dev/sdb: 976754646 sectors, 3.6 TiB
Logical sector size: 4096 bytes
Disk identifier (GUID): E6893923-5730-40DA-A41F-88173F191BEA
Partition table holds up to 128 entries
First usable sector is 6, last usable sector is 976754640
Partitions will be aligned on 256-sector boundaries
Total free space is 459 sectors (1.8 MiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1             256       976754431   3.6 TiB     0700  

Command (? for help):

Achja, habe auch noch einmal “dmesg --follow” ausgeführt:
Beim anstecken:

 2032.125268] usb 4-2: new SuperSpeed USB device number 3 using xhci_hcd
 2032.147658] usb 4-2: New USB device found, idVendor=174c, idProduct=55aa
 2032.147670] usb 4-2: New USB device strings: Mfr=2, Product=3, SerialNumber=1
 2032.147675] usb 4-2: Product: USB 3.0 Device
 2032.147679] usb 4-2: Manufacturer: Intenso
 2032.147683] usb 4-2: SerialNumber: 90300000000000001C46
 2032.153234] scsi3 : uas
 2032.153758] scsi 3:0:0:0: Direct-Access     ASMT     2105             0    PQ: 0 ANSI: 6
 2032.154525] sd 3:0:0:0: Attached scsi generic sg2 type 0
 2032.154761] sd 3:0:0:0: [sdb] Spinning up disk...
 2033.155994] ...........ready
 2043.188248] sd 3:0:0:0: [sdb] 976754646 4096-byte logical blocks: (4.00 TB/3.63 TiB)
 2043.188890] sd 3:0:0:0: [sdb] Write Protect is off
 2043.188900] sd 3:0:0:0: [sdb] Mode Sense: 43 00 00 00
 2043.189151] sd 3:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
 2043.190217] sd 3:0:0:0: [sdb] 976754646 4096-byte logical blocks: (4.00 TB/3.63 TiB)
 2043.213648]  sdb: sdb1
 2043.214328] sd 3:0:0:0: [sdb] 976754646 4096-byte logical blocks: (4.00 TB/3.63 TiB)
 2043.215015] sd 3:0:0:0: [sdb] Attached SCSI disk

Beim abziehen:

 2132.271771] usb 4-2: USB disconnect, device number 3
 2132.272820] sd 3:0:0:0: [sdb] Synchronizing SCSI cache
 2132.391535] sd 3:0:0:0: [sdb]  
 2132.391544] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK

timo08 · August 14, 2016, 1:38pm

Danke an alle die versucht haben mir bei dem Problem zu helfen. :good:
Ich habe Kontakt zu einem Bekannten eines Bekannten aufgenommen, der sich mit solchen Dingen einigermaßen auskennt.
Zitat: “Deine Daten sind total Schrott!”.
Habe jetzt neu formatiert und naja setze wieder auf GPT ;D

Also dann, vielen Dank für die Bemühungen.
mfg

Akoellh · August 14, 2016, 2:04pm

Am Sun, 14 Aug 2016 11:46:02 GMT
schrieb timo08 <timo08@no-mx.forums.microfocus.com>:

> Zitat: “Deine Daten sind total Schrott!”.

So direkt wollte ich es mit den für mich vorhandenen Infos nicht sagen, aber
ja, das war zu befürchten.

> Habe jetzt neu formatiert und naja setze wieder auf GPT ;D
>

Da spricht im Prinzip auch nichts dagegen (aber auch nichts dafür, siehe
weiter unten), aber ich frage mich, ob btrfs für eine externe Platte als
Datenpartition (sic!) wirklich Sinn macht.

Anderer Tipp:

Platte unbedingt mit badblocks und den smartmontools auf Fehler untersuchen.

Sofern die Platte nicht selbst einen abbekommen hat (der I/O-Error würde mir
Sorgen machen), hat es Dir "nur "die Partition bzw. das Dateisystem geshreddert.

Da nur eine Partition drauf war, waren alle Daten weg. Man sollte sich
vielleicht überlegen mehr als eine Partition anzulegen (und die Daten je nach
Bedarf sinnvoll aufteilen), aber das ist Geschmackssache.

Und zu guter letzt noch eine allgemeine Bemerkung, bei nur einer Partition ist
es komplett wurscht, ob man GPT oder den alten “msdos”-Typ für die
Partitionstabelle verwendet, sofern man die Platte nicht an irgendwelchen
“archaischen” Betriebssystemen verwenden will (die kein GPT beherrschen).

AK

–
Never attribute to malice that which can be adequately explained by stupidity.
(R.J. Hanlon)

timo08 · August 14, 2016, 2:26pm

Also das mit badblocks ist gar keine so schlechte Idee, da werde ich mich gleich mal dransetzen.
Ich denke ich erstelle 2 Partitionen, reiserfs für alles mögliche und ext3 für Filmbackups undso.
Dachte bisher immer dass sich GPT bei Fehlern leichter reparieren lässt als MBR.

Bei badblocks einfach “badblocks -svvn -c 64 /dev/sda” oder
kann man anstatt den 64 auch mehr Blöcke lesen lassen, da das bei 4TB durchaus dauern könnte?

Akoellh · August 14, 2016, 4:01pm

Am Sun, 14 Aug 2016 12:36:01 GMT
schrieb timo08 <timo08@no-mx.forums.microfocus.com>:

> Bei badblocks einfach “badblocks -svvn -c 64 /dev/sda” oder
> kann man anstatt den 64 auch mehr Blöcke lesen lassen, da das bei 4TB
> durchaus dauern könnte?

Einfach ausprobieren, -vv zeigt ja einen
Fortschritt an, dann kann man hochrechnen
Sollten schlechte Blöcke gefunden werden, dann würde ich mir überlegen, ob
man nicht besser die Platte ersetzt

AK

–
Never attribute to malice that which can be adequately explained by stupidity.
(R.J. Hanlon)