Ripristino di un filesystem ext4 con journal corrotto

Ho un disco rigido che sembra aver sviluppato una sorta di problema hardware nel diario. Ciò impedisce il caricamento dell'unità. L'esecuzione dei mount -r -t ext4 /dev/sda5 /mnt/rootrisultati nel seguente kernel spew:

[ 1420.671055] ata1.00: exception Emask 0x0 SAct 0x1000000 SErr 0x0 action 0x0
[ 1420.673862] ata1.00: irq_stat 0x40000008
[ 1420.676600] ata1.00: failed command: READ FPDMA QUEUED
[ 1420.679326] ata1.00: cmd 60/40:c0:a8:9d:0a/00:00:08:00:00/40 tag 24 ncq 32768 in
[ 1420.679326]          res 41/40:40:e1:9d:0a/00:00:08:00:00/00 Emask 0x409 (media error) <F>
[ 1420.685014] ata1.00: status: { DRDY ERR }
[ 1420.687858] ata1.00: error: { UNC }
[ 1420.761064] ata1.00: configured for UDMA/133
[ 1420.763863] sd 0:0:0:0: >[sda] Unhandled sense code
[ 1420.766653] sd 0:0:0:0: >[sda]  
[ 1420.769364] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 1420.772104] sd 0:0:0:0: >[sda]  
[ 1420.774780] Sense Key : Medium Error [current] [descriptor]
[ 1420.777491] Descriptor sense data with sense descriptors (in hex):
[ 1420.780249]         72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 
[ 1420.783175]         08 0a 9d e1 
[ 1420.785972] sd 0:0:0:0: >[sda]  
[ 1420.788730] Add. Sense: Unrecovered read error - auto reallocate failed
[ 1420.791545] sd 0:0:0:0: >[sda] CDB: 
[ 1420.794331] Read(10): 28 00 08 0a 9d a8 00 00 40 00
[ 1420.797242] end_request: I/O error, dev sda, sector 134913505
[ 1420.800072] ata1: EH complete
[ 1420.800077] JBD2: Failed to read block at offset 2748
[ 1420.812529] JBD2: recovery failed
[ 1420.815275] EXT4-fs (sda5): error loading journal

Capisco a malapena cosa significhi, ma sembra sicuramente un problema hardware che impedisce il caricamento del diario. C'è un modo per aggirare questo? Il diario, ad esempio, può essere spostato in un offset diverso lasciando il resto del disco per lo più intatto? Non ho intenzione di continuare a utilizzare l'unità; Voglio solo montarlo in modo da poter copiare alcuni file cruciali.

Per montarlo in sola lettura, senza riprodurre il diario in modo da poter accedere ai tuoi file (probabilmente perderai alcune modifiche che non sono ancora state impegnate nei normali fs):

mount -o ro,noload ...

Dai un'occhiata all'output di smartctl -a /dev/sda. Se non si tratta di un problema con il cavo, il disco potrebbe morire. Se non si dispone di un backup recente, provare a copiare il contenuto del dispositivo a blocchi (senza montaggio) utilizzando dd_rescue o dd con le rispettive opzioni.

Dopodiché puoi provare hdparm --write-sector(sempre divertenti queste opzioni "MOLTO PERICOLOSE" ...).

Un'altra opzione è quella di creare un dispositivo DM che ignori i settori difettosi. Ciò non recupera il loro contenuto, ovviamente. È necessario convertire l'offset sda (134913505) in un offset sda5 (scoprire il numero del primo settore di sda5 e sottrarlo). Supponiamo che l'offset di sda5 sia 12345. Si crea un dispositivo a blocchi il cui settore 12345 non è mappato su sda5 ma da qualche altra parte (ad es. Dispositivo loop). La definizione del dispositivo (per dmsetup create) è simile alla seguente:

0 12345 linear /dev/sda5 0
12345 1 linear /dev/loop0 0
12346 99987653 /dev/sda5 12345

# format:
# logical_start_sector num_sectors linear destination_device start_sector

Non sarai così fortunato che esiste un solo settore difettoso. Puoi mappare quanti ne vuoi (risultando nel dispositivo DM che fornisce zeri per quei settori ma che è scrivibile) ma calcolare gli offset in loop0 può diventare divertente. Un'altra opzione sarebbe quella di utilizzare un dispositivo virtuale della stessa dimensione per la rimappatura e utilizzare il thin provisioning o un'istantanea (con dimensioni di chunk piccole, 1 settore, ad esempio) di un dispositivo target zero.

Modifica 1

Il dispositivo loop non dovrebbe puntare a un file sullo stesso disco (sda), ovviamente.

È possibile avviare in modalità di ripristino, in cui FS sarà montato in sola lettura e copiare i tuoi file.