/home nicht mehr schreibbar, Start endet in Konsole

[schorsch_76]

@MSFree: Ich nutze btrfs seit vielen Jahren ohne Probleme auf dem Desktop, Pi4 oder BBB. Mit btrfsmaintenance hab ich auch keine Probleme und das Filesystem wird regelmässig "gewartet".

[linuxlooser]

noch kurz zur Ergänzung, weil ich die Daten gerade da habe: die beiden 2TB-Platten oben sind WD Blue aus Mitte 2017 - haben also im PC am heimischen Schreibtisch stehend für e-mails, Webseiten schreiben, Bilder editieren und das übliche Web-Surfen gerade 4 Jahre gehalten (die Hälfte davon passiv, weil die jeweils andere Platte im Einsatz war, s. o.) ...

[wanne]

Und noch kurz wie du die Datei zum Block bekommst.
Beispiel: Block: 4935609
Auf der Platte:

Code: Alles auswählen

 fdisk -l /dev/sda
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt

Device        Start      End  Sectors  Size Type
/dev/sda1      2048   278527   276480  135M Linux filesystem
/dev/sda2    278528 68638719 68360192 32.6G Linux filesystem
/dev/sda3  68638720 83884031 15245312  7.3G Linux swap

Code: Alles auswählen

$ calc 4935609-278528
4657081

=> Der 4378553ste Block auf sda2
Nun muss man aufpassen Oben steht, dass die Festplatte in 512Byte Blöcken rechnet. ext4 rechnet aber immer in 4kiB-Blöcke. => Um auf die Blocknummer im Dateisystem zu kommen musst du durch 8 teilen:

Code: Alles auswählen

echo -e "open /dev/sda2\n icheck $((4657081/8))" | debugfs -f -
debugfs:  icheck 582135
Block   Inode number
582135  1707692

=> Inode nummer 1707692 gehört zu dem Block.

Code: Alles auswählen

find / -xdev -inum 1707692
/usr/bin/xxd

=> Block liegt in xxd:
Die beiden letzten Chckes können prinzipiell beide fehlschlagen: Der erste, nach dem inode wenn der Platz auf der Platte schlicht frei ist, der 2. nach der Datei auf dem inode Wenn an der Stelle keine Datei sondern Metadaten liegen.

Gegencheck:

Code: Alles auswählen

filefrag /usr/bin/xxd -v
File size of /usr/bin/xxd is 18552 (5 blocks of 4096 bytes)
 ext:     logical_offset:        physical_offset: length:   expected: flags:
   0:        0..       4:     582134..    582138:      5:             last,eof

Ich hoffe ich habe jetzt keinen off by one error gemacht...

[linuxlooser]

Nun muss man aufpassen Oben steht, dass die Festplatte in 512Byte Blöcken rechnet. ext4 rechnet aber immer in 4kiB-Blöcke. => Um auf die Blocknummer im Dateisystem zu kommen musst du durch 8 teilen:

Bei mir kommt dieses Mischmasch aus 512Byte und 4k:

Code: Alles auswählen

~# fdisk -l /dev/sda
Disk /dev/sda: 1,8 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: WDC WD20EZRZ-00Z
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt

Device         Start        End    Sectors  Size Type
/dev/sda1       2048     411647     409600  200M EFI System
/dev/sda2     411648  136726527  136314880   65G Linux filesystem
/dev/sda3  136726528  187058175   50331648   24G Linux swap
/dev/sda4  187058176 3907028991 3719970816  1,7T Linux filesystem

War mir nicht sicher, ob ich dann auch durch 8 teilen muß, aber

Code: Alles auswählen

2000398934016 ÷ 3907029168 = 512

also wohl ja.

Und als Wert kann ich dann den aus dem Log nehmen?

Code: Alles auswählen

Oct 10 09:11:40 Rechner kernel: [1253524.924805] print_req_error: I/O error, dev sda, sector 3435913264

Code: Alles auswählen

3435913264 - 187058176 = 3248855088

Dann käme

Code: Alles auswählen

~# echo -e "open /dev/sda4\n icheck $((3248855088/8))" | debugfs -f -
debugfs 1.44.5 (15-Dec-2018)
debugfs: open /dev/sda4
debugfs:  icheck 406106886
Block	Inode number
406106886	<block not found>

Die beiden letzten Chckes können prinzipiell beide fehlschlagen: Der erste, nach dem inode wenn der Platz auf der Platte schlicht frei ist

was - wenn ich nicht grundsätzlich was falsch gemacht habe, beruhigend wäre ...

[wanne]

Bei mir kommt dieses Mischmasch aus 512Byte und 4k:

Ja. Grauenhaft. Der Grund ist, dass die Platte eigentlich 4k Blöcke hat. Aber nach außen zerteilt sie jeden in 8 Einzelteile tut so als hätte sie 512Byte, weil ältere Windows-Versionen (Alles vor Windows 10) nur damit umgehen können. Weil das so ist, gelten die 512.

was - wenn ich nicht grundsätzlich was falsch gemacht habe, beruhigend wäre ...

Nein. Ganz im Gegenteil. Wenn das dir die Zuordnung kaputt schießt welche Daten zu welcher Datei gehören, können halt prinzipiell alle Dateien Probleme haben...

[linuxlooser]

Kann ich eigentlich eine mittels `gdisk` gesicherte Partitionstabelle auf eine neue Platte zwar gleicher Größe, aber anderen Typs (WD black akutell vs. WD blue von vor 4 Jahren) übertragen?

Als Halblaie könnten mir evtl. ein paar Unwägbarkeiten einfallen

[GregorS]

Als Halblaie ...

Grundsätzlich: Wenn eine Platte Ärger macht, immer und zu allererst ein "rohes" Backup der vollständigen Platte anfertigen. Ich mache das alle paar Monate und vor tiefgreifenden Konfigurationsänderungen mit dd.

Gruß

Gregor

[linuxlooser]

alle paar Monate (...) mit dd.

Scheidet aus, wir sprechen hier von 2TB - hab nicht so viele redundante Platten rumliegen ...
Hab die vollständigen Daten parallel auf 2 PCs zzgl. einer ext. Platte, dort mit Versionierung.
Und vom Betriebssystem gibt's gelegentliche Timeshift-Snapshots.

Mir geht es aktuell (nachdem gestern die Ersatzplatte eingetroffen ist) darum, ob ich alles von Hand neu aufsetzen muß oder ob ich die Partitionstabelle aus dem gdisk-Backup der alten Platte verwenden kann und dann den letzten Timeshift-Stand einspielen ...
(mit dd könnte ich zum jetzigen Stand eh nur eine kaputte Platte kopieren)

[MSfree]

dd halte ich auch für ungeeinet als Backup in diesem Fall. dd kopiert ja auch die unbennutzen Plattensektoren, was einerseits völlig überflüssig ist und andererseits Platz benötigt.

Backups auf Dateibasis sind da deutlich sinnvoller.

Mir geht es aktuell (nachdem gestern die Ersatzplatte eingetroffen ist) darum, ob ich alles von Hand neu aufsetzen muß oder ob ich die Partitionstabelle aus dem gdisk-Backup der alten Platte verwenden kann und dann den letzten Timeshift-Stand einspielen ...

Das Anlegen eine neuen Partitionstabelle ist ja nun kein so schwieriges Unterfangen. Die alte Partitiontabelle würde ich nicht nutzen, denn das funktioniert nur dann reibungslos, wenn die neue Platte exakt genauso vielie Bytes hat wie die alte. Schon 4096 Bytes Unterschied kann problematisch werden. Ausserdem kann man sich beim Neuanlegen auch mal Gedanken machen, ob die alte Partitionierung sinnvoll war oder ob man lieber die Aufteilung etwas ändert.

Den letzten Timeshift-Stand kannst du auch auf eine frisch partitionierte Platte einspielen.

[linuxlooser]

Die alte Partitiontabelle würde ich nicht nutzen, denn das funktioniert nur dann reibungslos, wenn die neue Platte exakt genauso vielie Bytes hat wie die alte. Schon 4096 Bytes Unterschied kann problematisch werden.

Das war eine meiner Bedenken, danke!

Den letzten Timeshift-Stand kannst du auch auf eine frisch partitionierte Platte einspielen.

Werd ich probieren.

[linuxlooser]

... der Vollständigkeit halber:

Den letzten Timeshift-Stand kannst du auch auf eine frisch partitionierte Platte einspielen.

Wenn - wie beschrieben - die Partitionen neu angelegt werden, dann kommen solche schöne Meldungen:

Code: Alles auswählen

[ 0;31m*0;1;31m*0m0;31m*  0m] A start job is running for /dev/disk/by-uuid/2b05a558-4e48-4849-a9cb-c6dfc8b5cb09 (1min 30s / 1min 30s)
[0;1;31m TIME 0m] Timed out waiting for device 0;1;39m/dev/disk/by-uuid/2b05a558-4e48-4849-a9cb-c6dfc8b5cb090m.
K[0;1;33mDEPEND0m] Dependency failed for 0;1;39m/dev/disk/by-uuid/2b05a558-4e48-4849-a9cb-c6dfc8b5cb090m.
[0;1;33mDEPEND0m] Dependency failed for 0;1;39mSwap0m.

beim Hochfahren.

Ist auch logisch, denn die Partionen heißen ja jetzt anders.
Deshalb in gparted die UUIDs angucken (komischerweise konnte ich mit den Ausgaben von gdisk hier nix anfangen) und aus z. B. 'nem Live-System die /etc/fstab korrigieren, die aus der Timeshift-Sicherung eingespielt wurde ...

Erst danach dann starten.