Hallo!
Ich habe noch einige alte Dualboot-Festplatten deren Daten ich sichern ( ob wichtig oder nicht sehe ich nach dem auslesen ) möchte und bekomme, bei einer davon, auf der Linuxpartition, folgenden Fehler:
“To repair filesystem using alternate superblock, run fsck.ext4 -p superblock -B blocksize device”
und in testdisk bekomme ich die Ausgabe " btrfs superblock 102400000 blocksize=4096"
In gparted bekomme ich folgende Ausgaben:
Die Platte war - meiner Erinnerung nach - mit BTRFS formatiert und in Testdisk finde ich keine Btrfs-Unterstützung. ein einhängen ist daher nicht möglich.
Kann mir jemand sagen wie ich die Partition wieder einsehen kann?
Vielen Dank im voraus.
MfG R.Lehmeier
Hallo @Lehmeier 
Überprüfen könntest du eine btrfs Partition mit:
sudo btrfs check /dev/sdb3
Falls tatsächlich Fehler gefunden wurden, dann versuch es mit der automatischen Reparatur:
sudo btrfs check --repair --force /dev/sdb3
Die Partition darf auf keinen Fall eingehängt sein!
Logs zu BTRFS werden in den Kernel Nachrichten angezeigt: sudo dmesg --follow
1 Like
Hier hängt er sich mit der Meldung :
adding new data backref on 2914500608 root 5 owner 8652544 offset 0 found 1
Repaired extent references for 2914500608
block group [2176843776 1073741824] used 1073770496 but extent items used 1073700864
super bytes used 330129768448 mismatches actual used 330129698816
auf.
Da die Ausgabe zu lang für das Forum ist habe ich Sie mal bei pastebin.com hochgeladen:
@Lehmeier Ich habe deinen Text lesbarer gemacht und hoffe du fühlst dich beleidigt oder ähnliches. 
Auf jeden Fall scheint das Problem bei den Prüfsummen zu sein, also einige Dateien scheinen fehlerhaft zu sein.
Was meinst du mit hängen? Gibt es keine Festplattenaktivität?
Prüf es mal mit:
sudo iotop
Manchmal dauert es einfach ein wenig. Wenn keine Fehlermeldung angezeigt wird oder der Vorgang abbricht, dann weiterlaufen lassen.
Auch nützlich, und sollte vor einer Reparatur gemacht werden:
sudo btrfs scrub start -Bf /dev/sdb3
Status anzeigen:
watch -n1 sudo btrfs scrub status /dev/sdb3
Das prüft alle Prüfsummen und korrigiert Dateien, falls möglich.
Ich habe natürlich nichts dagegen wenn du etwas lesbar machst, aber leider funktionieren die Befehle nicht, weil ich dafür die Platte einhängen müßte und ich bekomme dann diese Meldung:
Falls der Superblock das Problem ist:
sudo btrfs rescue super-recover -v -y /dev/sdb3
Ansonsten versuch die Chunks wiederherzustellen:
sudo btrfs rescue chunk-recover -v -y /dev/sdb3
Das kann je nach Größe der Partition sehr lange dauern.
Falls du sowas wie:
? replay_one_dir_item+0xb5/0xb5 [btrfs]
? walk_log_tree+0x9c/0x19d [btrfs]
? btrfs_read_fs_root_no_radix+0x169/0x1a1 [btrfs]
? btrfs_recover_log_trees+0x195/0x29c [btrfs]
? replay_one_dir_item+0xb5/0xb5 [btrfs]
? btree_read_extent_buffer_pages+0x76/0xbc [btrfs]
? open_ctree+0xff6/0x132c [btrfs]
in den Kernel Nachrichten dmesg siehst, dann solltest du die log löschen:
sudo btrfs rescue zero-log /dev/sdb3
Ich bekomme immer diese Meldung. Der Vorgang wird abgebrochen.
sudo btrfs rescue chunk-recover -v -y /dev/sdb3
[sudo] Passwort für ralf:
All Devices:
Device: id = 1, name = /dev/sdb3
Scanning: 22653878272 in dev0scan chunk headers error
Chunk tree recovery aborted
Dann ist dein Dateisystem wirklich im A…Eimer. Wenn alles nichts hilft, dann muss man wohl oder übel die Keule nehmen:
Also zuerst den Space-Cache löschen:
sudo btrfs check --clear-space-cache v1 /dev/sdb3
Die folgenden Befehle können zu Datenverlust führen, da der Ist-Zustand verworfen und komplett neu erstellt wird und Dateiteile, die nicht “registriert” sind verloren gehen.
Prüfsummen neu erstellen:
sudo btrfs check --init-csum-tree /dev/sdb3
“Umfang-Baum” neu erstellen:
sudo btrfs check --init-extent-tree /dev/sdb3
Dann nochmal versuchen zu reparieren:
sudo btrfs check --check-data-csum --progress --repair /dev/sdb3
Nach der Eingabe von :
sudo btrfs check --init-csum-tree /dev/sdb3
lief es einige Zeit durch. Jetzt scheint es seit ca 30 Stunden bei der Ausgabe zu stehen:
…
Repaired extent references for 2914496512
ref mismatch on [2914500608 8192] extent item 0, found 1
data backref 2914500608 root 5 owner 8652544 offset 0 num_refs 0 not found in extent tree
incorrect local backref count on 2914500608 root 5 owner 8652544 offset 0 found 1 wanted 0 back 0x55cc00326820
backpointer mismatch on [2914500608 8192]
adding new data backref on 2914500608 root 5 owner 8652544 offset 0 found 1
Repaired extent references for 2914500608
block group [2176843776 1073741824] used 1073770496 but extent items used 1073700864
super bytes used 329992224768 mismatches actual used 329992155136
Gelegentlich blinkt der Festplattenadapter, als ob etwas geschrieben oder darauf zugegriffen wird, aber die Ausgabe scheint sich nicht zu ändern - soll ich noch warten oder kann ich abbrechen?
@Lehmeier Ich bin mir da jetzt auch nicht sicher. “super byte” sollte ein synonym für Superblock sein. Also es wird Superblock “329992155136” verwendet, aber der Superblock "329992224768 " ist wahrscheinlich fehlerhaft, da die Prüfsumme nicht passt.
In den Kernel Logs, hat man ja diesen Fehler gesehen:
[ 163.007728] BTRFS info (device sdb3): flagging fs with big metadata feature
[ 163.007733] BTRFS info (device sdb3): disk space caching is enabled
[ 163.007734] BTRFS info (device sdb3): has skinny extents
[ 163.139122] BTRFS critical (device sdb3): corrupt leaf: root=2 block=118678290432 slot=152 bg_start=2176843776 bg_len=1073741824, invalid block group used, have 1073770496 expect [0, 1073741824)
[ 163.139126] BTRFS error (device sdb3): block=118678290432 read time tree block corruption detected
[ 163.153117] BTRFS critical (device sdb3): corrupt leaf: root=2 block=118678290432 slot=152 bg_start=2176843776 bg_len=1073741824, invalid block group used, have 1073770496 expect [0, 1073741824)
[ 163.153121] BTRFS error (device sdb3): block=118678290432 read time tree block corruption detected
[ 163.153140] BTRFS error (device sdb3): failed to read block groups: -5
[ 163.154108] BTRFS error (device sdb3): open_ctree failed
-5 bedeutet ja auf einen Eingabe/Ausgabefehler und generell würde man hier von A) einem defekten Dateisystem ausgehen oder B) von einem Badblock bis hin zu einer defekten Festplatte.
Wenn das jetzt seit 30 Stunden so bleibt und in dem Kernel Log ein Eingabe/Ausgabefehler zu finden ist, kann man hier abbrechen.
Generell müsste alle Superblocks identisch sein. Normalerweise sollte das:
dieses Problem lösen.
Ich denke @andreas85 hat ein wenig mehr Ahnung/Erfahrung als ich in dem Fall. Falls du (@andreas85) das siehst, könntest du dir das auch einmal anschauen?
Das hört sich so an, als ob da mal ein ext4 gewesen war, und jetzt btrfs ist.
-
Vielleicht ein ext4 auf btrfs konvertiert und nicht aufgeräumt ?
-
Nach dem Konvertieren prüfen ob alles da ist, dann unbedingt den ext4_saved snapshot löschen !
-
Nach dem Konvertieren niemals einen kernel starten, der btrfs nicht kennt.
Ab diesem Punkt würde ich das Dateisystem nur read-only von einem Live-manjaro aus anfassen um die Daten zu retten (keine Reparaturversuche).
- Ein btrfs zu “reparieren” kann gut gehen, muß aber nicht.
-
Vor der Reparatur hat man die besten Chancen für Datenrettung.
- Ich hab um btrfs check und die ganzen reparatur-optionen immer einen großen Bogen gemacht (wegen der eindringlichen Warnungen dazu)
Wenn das Dateisystem ursprünglich ext4 war, auf btrfs konvertiert wurde, und danach nochmal als ext4 eingehängt war, oder mit ext-tools bearbeitet wurde, (was ich vermute), wird nicht viel zu retten sein. Ext4 schert sich nicht darum und schreibt über die btrfs-chunks hinweg.
Das vom Programm vorgeschlagene fsck.ext4 ist in diesem scenario desaströs für ein btrfs
Wenn bei mir ein btrfs “unrettbar” war, hat es sich trotzdem IMMER noch readonly mounten lassen. Dann waren alle Daten von vor dem crash voll lesbar. Wegen CoW wird bei btrfs ja nicht in die alten chunks geschrieben. Dass das geklappt hat hat nichts mit besonderen Kenntnissen zu tun, sondern mit besonderer Vorsicht
- Das hat bei mir selbst bei einem RAID geklappt, bei dem die verschiedenen Platten teilweise geclont, und dann zeitweise in unterschiedlicher kombination “unabsichtlich” gemountet und benutzt(!) worden waren
- Oder bei einer VM der der dynamische Festplattenspeicher begrenzt worden war, so daß irgendwann alle Schreibbefehle schief gingen.
Wichtig ist es auf keinen Fall ein Rettungssystem zu nehmen, das btrfs nicht kann, oder einen alten kernel verwendet !
- Also auf keinen Fall an einem Jahre alten noch funktionierenden Linux mit dieser Platte arbeiten.
-
Am besten ein aktuelles Live-manjaro oder noch besser ein updatebarer live-manjaro-usb-stick
Läßt sich die Platte denn readonly mounten ?
Soviel ich noch weiß wurde die Partiotion nur in btrfs angelegt.
Ich habe es mal im Terminal versucht, mit sudo mount -o ro /dev/sdb3 /run/media/
eingehangen und bekam “mount: /run/media: Falscher Dateisystemtyp, ungültige Optionen, der Superblock von /dev/sdb3 ist beschädigt, fehlende Kodierungsseite oder ein anderer Fehler.”
sudo btrfs rescue super-recover -v -y /dev/sdb3
All Devices:
Device: id = 1, name = /dev/sdb3
Before Recovering:
[All good supers]:
device name = /dev/sdb3
superblock bytenr = 65536
device name = /dev/sdb3
superblock bytenr = 67108864
device name = /dev/sdb3
superblock bytenr = 274877906944
[All bad supers]:
All supers are valid, no need to recover
Ich würde jetzt von einem Badblock auf der physischen Platte ausgehen. Da BTRFS das Badblock Tracking bisher nicht beherrscht (Project ideas - btrfs Wiki), wird es schwierig. Falls du noch einen Festplatte mit 500GB freien Speicher hast, mach einmal eine komplette Kopie deiner Partition:
sudo dd if=/dev/sdb3 of=/pfad/zu/festplatte bs=64K conv=noerror,sync status=progress
dd - ArchWiki
Um ehrlich zu sein, muss da jetzt Vorort ein Profi ran, der genau weiß was er tut, damit die Daten wieder lesbar werden.
Kann es auch ein leeres Verzeichnis auf einer anderen Platte oder muß es eine eigene Festplatte sein?
Würde es durch das kopieren wieder lesbar? Es währe doch nur eine reine Datensicherung, oder täusche ich mich?
Ich werde jedenfalls kein Geld dafür ausgeben - aber ich habe dazugelernt das btrfs noch lange nicht so weit ist das man im wertvolle Daten ( die hier zum Glück nicht vorlagen ) anvertrauen kann.
Ich werde in Zukunft also wieder nur EXT4 vertrauen.
Ja es sollte definitive NICHT die selbe Festplatte sein.
Ja das wäre eine Sicherung. Da mir keine weiteren aktuellen Kernel logs vorliegen, kann ich auch nichts weiteres sagen… Es gibt die Möglichkeit die Badblocks mit Nullen zu überschreiben auf der Sicherung, sodass es dann reparierbar wird.
Es gibt noch die Möglichkeit die Badblocks entsprechend diesem Wiki-Aartikel zu fixen: Identify damaged files - ArchWiki
Jedenfalls gibt es nur Hinweise darauf, aber keinen Nachweis.
sudo smartctl --all /dev/sdb
BTRFS ist schon soweit, aber bei einem Hardware-Defekt wird es schwierig. Selbst Ext4 kann da Probleme bekommen.
1 Like
Gegen einen bad block hilft bei btrfs nur btrfs-RAID !
(und das ist leichter zu beherrschen als Hardware-RAID)
Dann repariert sich btrfs aber von selbst wenn die Daten gelesen werden (z.B mit einem scrub)
Bei Hardware-RAID ist das ein richtiges Theater im Vergleich dazu.
1 Like
Ich dachte auch mehr an eine separate Festplatte oder an ein Verzeichnis auf meiner Externen Festplatte, auf der ich auch andere Sicherungen habe.
Nun zu deiner Abfrage:
sudo smartctl --all /dev/sdb
[sudo] Passwort für ralf:
smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.10.79-1-MANJARO] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Family: Western Digital Green
Device Model: WDC WD10EARX-00N0YB0
Serial Number: WD-WMC0T0131641
LU WWN Device Id: 5 0014ee 207360118
Firmware Version: 51.0AB51
User Capacity: 1.000.204.886.016 bytes [1,00 TB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Device is: In smartctl database [for details use: -P show]
ATA Version is: ATA8-ACS (minor revision not indicated)
SATA Version is: SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s)
Local Time is: Sat Nov 27 11:18:00 2021 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART Status command failed: Die Wartezeit für die Verbindung ist abgelaufen
SMART overall-health self-assessment test result: PASSED
Warning: This result is based on an Attribute check.
General SMART Values:
Offline data collection status: (0x82) Offline data collection activity
was completed without error.
Auto Offline Data Collection: Enabled.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: (18300) seconds.
Offline data collection
capabilities: (0x7b) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 2) minutes.
Extended self-test routine
recommended polling time: ( 179) minutes.
Conveyance self-test routine
recommended polling time: ( 5) minutes.
SCT capabilities: (0x30b5) SCT Status supported.
SCT Feature Control supported.
SCT Data Table supported.
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 1
3 Spin_Up_Time 0x0027 126 102 021 Pre-fail Always - 6658
4 Start_Stop_Count 0x0032 096 096 000 Old_age Always - 4115
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0
7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0
9 Power_On_Hours 0x0032 072 072 000 Old_age Always - 20549
10 Spin_Retry_Count 0x0032 100 100 000 Old_age Always - 0
11 Calibration_Retry_Count 0x0032 100 100 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 096 096 000 Old_age Always - 4109
192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 481
193 Load_Cycle_Count 0x0032 152 152 000 Old_age Always - 145627
194 Temperature_Celsius 0x0022 118 089 000 Old_age Always - 29
196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0
197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0
200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline - 0
SMART Error Log Version: 1
No Errors Logged
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Conveyance offline Interrupted (host reset) 90% 20313 -
# 2 Short offline Completed without error 00% 20300 -
# 3 Short offline Completed without error 00% 18662 -
# 4 Short offline Completed without error 00% 13538 -
# 5 Short offline Completed without error 00% 13143 -
# 6 Short offline Completed without error 00% 13102 -
# 7 Short offline Completed without error 00% 12967 -
# 8 Short offline Completed without error 00% 12637 -
# 9 Short offline Completed without error 00% 12512 -
#10 Short offline Completed without error 00% 12490 -
#11 Short offline Completed without error 00% 11670 -
#12 Short offline Completed without error 00% 11197 -
#13 Short offline Completed without error 00% 10981 -
#14 Short offline Completed without error 00% 8794 -
#15 Short offline Completed without error 00% 8767 -
SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.
Muss das Dateisystem nicht extra mit -t btrfs angegeben werden ?
Ich hab dann auch immer btrfs-root(subvol=/) gemountet. Dann sieht man eventuell verfügbare subvolumes/snapshots im Dateimanager.
Mein Befehl war: (da fehlt aber noch das -o ro)
sudo mount -t btrfs -o subvol=/ /dev/nvme0n1p3 /mnt/ROOT/
Scheint wohl, dass da noch nie ein Test gelaufen ist, oder es gab nie Badblocks, die neu zugewiesen wurden:
Dauer ca. 1min
sudo smartctl -t short /dev/sdb
Dauer ca 3 Std:
sudo smartctl -t long /dev/sdb
Damit werden die Smart-Daten aktualisiert.
