Wiki Ubuntu-it

Indice
Partecipa
FAQ
Wiki Blog
------------------
Ubuntu-it.org
Forum
Chiedi
Chat
Cerca
Planet
  • Pagina non alterabile
  • Informazioni
  • Allegati
  • Differenze per "Hardware/DispositiviPartizioni/Btrfs/Riparazione"
Differenze tra le versioni 25 e 26
Versione 25 del 01/10/2024 11.57.32
Dimensione: 13865
Autore: emanuc
Commento:
Versione 26 del 01/10/2024 12.34.18
Dimensione: 13768
Commento: paragrafi risistemati
Le cancellazioni sono segnalate in questo modo. Le aggiunte sono segnalate in questo modo.
Linea 16: Linea 16:
{{{#!wiki note
Nella guida viene preso come esempio il nome del dispositivo `/dev/sda2`; sostituirlo con il nome del dispositivo della partizione Btrfs (consultare [[Hardware/DispositiviPartizioni/Partizioni|IndividuarePartizioni]] questa guida per identificarlo).
}}}
Linea 18: Linea 22:
= Cosa fare se si verificano errori nel filesystem =
{{{#!wiki note
Nell'intero paragrafo uso come esempio il nome del dispositivo '''/dev/sda2''', sostituirlo con il nome del dispostivo della partizione Btrfs.
Per identificare il nome di una partizione, consultare il paragrafo: [[Hardware/DispositiviPartizioni/Partizioni|IndividuarePartizioni]]
}}}

== Salvare i dati ==
= Salvare i dati =
Linea 45: Linea 43:
=== Perché si verificano errori transid? === == Perché si verificano errori transid? ==
Linea 60: Linea 58:
== Controllo hardware == = Controllo hardware =
Linea 75: Linea 73:
== Controllo del filesystem == = Controllo del filesystem =
Linea 92: Linea 90:
== Riparazione == = Riparazione =
Linea 134: Linea 132:
== Recupero dati == = Recupero dati =
Linea 162: Linea 160:
== Recupero dei dati cancellati accidentalmente == = Recupero dei dati cancellati accidentalmente =
Linea 178: Linea 176:


Attenzione! Questa è una Pagina di prova. Le informazioni riportate potrebbero essere incomplete, errate e potenzialmente pericolose. Per contribuire alla realizzazione di questa pagina consultare la discussione di riferimento.

Guida verificata con Ubuntu: 22.04

Problemi in questa pagina? Segnalali in questa discussione

Introduzione

In questa guida sono descritte le procedure su come gestire la corruzione del filesystem Btrfs.

Nonostante Btrfs sia progettato con solide caratteristiche per rilevare e correggere la corruzione dei dati, ci sono ancora casi in cui il filesystem può subire danni a causa di problemi hardware. Ad esempio:

  • Guasti del controller o del firmware del disco: Un controller o firmware difettoso può inviare dati corrotti al filesystem senza segnalarlo correttamente, rendendo inefficaci i meccanismi di protezione di Btrfs. In alcuni casi, l'hardware può corrompere i dati a livello di interfaccia, aggirando i meccanismi di checksum.

  • Problemi nella memoria RAM: si pensi alla corruzione dei dati dovuta a bit errati; Btrfs non può fare molto per rilevare tali errori prima che i dati vengano scritti su disco. Ad esempio, se un errore di memoria altera i dati prima che vengano scritti su Btrfs, i checksum verranno calcolati sui dati già corrotti, quindi Btrfs non riuscirà a rilevare l'errore.

Nella guida viene preso come esempio il nome del dispositivo /dev/sda2; sostituirlo con il nome del dispositivo della partizione Btrfs (consultare IndividuarePartizioni questa guida per identificarlo).

Salvare i dati

In caso di corruzione, Btrfs per non propagare ulteriore corruzione passa automaticamente alla modalità di sola lettura. In questo scenario è possibile salvare i dati, ed è la prima cosa da fare prima di provare a riparare il filesystem.

  • Nel caso in cui il filesystem non sia montabile, provare a montarlo in sola lettura nella modalità “rescue”.
  • Abilita tutte le opzioni di recupero supportate (btrfs-progs 5.9):

    sudo mount -o ro,rescue=all /dev/sda2 /mnt
  • Prova a utilizzare gli slot root di backup all'interno del super blocco (btrfs-progs 5.9):

    sudo mount -o ro,rescue=usebackuproot /dev/sda2 /mnt
  • Salvare i dati e procedere alla riparazione del filesystem.

Se il filesystem non viene montato con le opzioni di salvataggio, ad esempio questo capita nel caso in cui riceviamo un errore simile: [ 4007.489730] BTRFS error (device vdb): parent transid verify failed on 30736384 wanted 10 found 8. L'errore parent transiid verify è il peggior errore per un filesystem Btrfs. Passare direttamente al paragrafo Recupero dati per cercare di recuperare più dati possibili. Ulteriori dettagli sull'errore critico parent transid

Perché si verificano errori transid?

Linux utilizza Flush/FUA (precedentemente noto come barriers) per garantire che nessun dato aggiuntivo venga scritto su disco prima che Flush/FUA sia completato. Questo è essenziale, poiché i dispositivi di archiviazione possono riordinare le scritture nella loro cache per ottimizzare le prestazioni. Flush/FUA assicura che i dati su disco siano in un ordine coerente, anche in caso di interruzione dell'alimentazione.

Quando si verifica un errore di Parent Transid Verify Failed, spesso significa che il dispositivo di archiviazione non ha rispettato correttamente Flush/FUA. In alcuni casi, potrebbe esserci stato un problema con un bus o un ripristino del dispositivo, che ha causato la perdita di dati in transito o nella cache del disco, portando a un filesystem incoerente.

Altre situazioni che possono portare a errori transid sono:

  • Bug logici: le strutture del filesystem non sono state aggiornate o memorizzate correttamente.

  • Scritture errate: il dispositivo di archiviazione non ha memorizzato i dati all'indirizzo corretto, sovrascrivendo altri dati.

  • Il dispositivo di archiviazione a blocchi (hardware o emulato) non è affidabile e perde dati tra le transazioni, causando confusione nel filesystem.

  • Scritture perse senza una corretta gestione degli errori: la scrittura sembra essere riuscita a livello del filesystem, ma a livelli inferiori si sono verificati problemi non propagati correttamente.

  • Modalità di sospensione: a volte può confondere il kernel o la cache dell'unità, causando perdite di dati e gli stessi tipi di errori.

Fonte

Controllo hardware

Prima di procedere al tentativo di riparazione è importante escludere problemi hardware, perché un tentativo di riparazione su un hardware difettoso non fa altro che peggiorare la corruzione del filesystem.

Se il dispositivo mente sulla propria capacità di supportare le barriere, Linux non ha modo di sapere quando i dati sono effettivamente su disco. È quindi molto difficile mitigare completamente il rischio. Se il tuo dispositivo è in un alloggiamento USB, prova a passare ad un altro alloggiamento o ad inserirlo direttamente sul bus SATA. È relativamente comune che i bridge USB-SATA utilizzati negli alloggiamenti non implementino tutte le funzionalità ATA, non abbiano una buona gestione degli errori o semplicemente mentono sulle capacità del dispositivo. Un'esperienza personale di questo è stata un contenitore USB che non implementava correttamente il protocollo USB attached SCSI (UAS) e perdeva scritture durante il carico pesante. In questo caso è stato utile disabilitare il modulo del kernel UAS.

La disabilitazione della cache di scrittura è una possibile mitigazione del problema. Riduce leggermente le prestazioni, ma dovrebbe impedire il riordino della cache di scrittura. Usa hdparm per disabilitare la cache di scrittura. Fonte

  1. Test del disco: Per un controllo del disco consultare questo paragrafo

  2. Test della Ram: La versione live di Ubuntu fornisce un modo semplice per testare la tua RAM eseguendo memtest86. Memtest86 viene eseguito selezionando il menu GRUB all'avvio del computer e selezionando la voce memtest. Memtest86 eseguirà molti test diversi sulla tua ram, alcuni dei quali possono richiedere più di 30 minuti. Per testare a fondo la tua ram, lascia che memtest86 venga eseguito durante la notte.
  3. Stabilità alimentatore
  4. Controllo dei cavi sata

Controllo del filesystem

Per procedere al controllo del filesystem la soluzione più sicura e attendibile è farlo a filesystem smontato. Se è una partizione di sistema, si raccomanda di utilizzare una live che includa l’ultima versione stabile di btrfs-progs. Per controllare l'ultima versione di btrfs-progs, consultare il tag release dal progetto upstream.

  • Controllo in modalità "originale":

    sudo btrfs check /dev/sda2
  • Controllo in modalità "lowmem", potrebbe restituire risultati più dettagliati rispetto alla modalità “originale”, in più utilizza meno memoria Ram:

    sudo btrfs check --mode=lowmem /dev/sda2
  • Verifica checksum dei dati. È essenzialmente uno scrub offline, ma senza riparare i dati dalle copie, se presenti:

    sudo btrfs check --check-data-csum /dev/sda2

Riparazione

  • È possibile determinare se è necessario cancellare l'albero dei log in base al backtrace del kernel. Se gli errori sono come quelli sotto, Le parole chiave da cercare sono 'open_ctree' che dice che è durante il montaggio e i nomi delle funzioni che contengono replay, ripristino o log_tree:

    ? 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]
  • Cancella l'albero dei log:

    sudo btrfs rescue zero-log /dev/sda2
  • Tenta di recuperare i metadati corrotti relativi ai "chunk" (i blocchi di dati):

    sudo btrfs rescue chunk-recover /dev/sda2
  • Correggere le dimensioni del dispositivo e i valori dei byte totali del superblocco che non corrispondono. A partire dal Kernel 4.11, le dimensioni del dispositivo vengono controllate in modo più rigoroso e questo potrebbe causare un disallineamento del valore memorizzato dei byte totali. Vedere il messaggio di errore esatto qui sotto. Il kernel più recente si rifiuterà di montare il file system se i valori non corrispondono. Questo errore non è fatale e può essere risolto. Questo comando correggerà i valori dimensionali del dispositivo, se possibile:

    BTRFS error (device sdb): super_total_bytes 92017859088384 mismatch with fs_devices total_rw_bytes 92017859094528
    WARNING: CPU: 3 PID: 439 at fs/btrfs/ctree.h:1559 btrfs_update_device+0x1c5/0x1d0 [btrfs]
  • Correggere le dimensioni del dispositivo e i valori dei byte totali del superblocco che non corrispondono:

    sudo btrfs rescue fix-device-size /dev/sda2

La modalità riparazione potrebbe peggiorare la corruzione del filesystem, Avviare questa modalità solo dopo aver copiato i dati al backup e se le altre operazioni di recupero non hanno funzionato. C'è un avviso e un ritardo di 10 secondi quando questa opzione viene eseguita senza "--force".

  • Avvia la modalità riparazione e tenta di risolvere i problemi ove possibile:

    sudo btrfs check --repair /dev/sda2
  • Se la riparazione è andata a buon fine e il filesystem è di nuovo in modalità RW, è raccomandato eseguire uno scrub per verificare l'integrità dei dati. La verifica deve essere eseguita con il filesystem montato:

    sudo btrfs scrub start -B /mountpoint

Recupero dati

Se il filesystem non viene montato nemmeno in modalità "rescue".

Il comando btrfs restore viene utilizzato per recuperare file da un filesystem Btrfs danneggiato senza montarlo. Questo comando è utile quando il filesystem non può essere montato normalmente a causa di corruzione o altri errori gravi. Invece di tentare di riparare il filesystem, btrfs restore cerca di copiare i dati leggibili in un'altra posizione.

  • Preparare un dispositivo per poter copiare i dati, di dimensione uguale o maggiore alla quantità di dati prensenti sul filesystem.
  • Montare il dispositivo. Consultare il paragrafo: Montare partizioni

  • Come esempio, utilizzerò il percorso: /mnt/recupero. Modifica il percorso in base alla posizione di mount del disco di recupero
  • Recupera tutti i file :

    sudo btrfs restore /dev/sda2 /mnt/recupero
  • Ignora i file corrotti:

    sudo btrfs restore -i /dev/sda2 /mnt/recupero
  • Recuperare solo un file specifico:

    sudo btrfs restore -o /percorso/del/file /dev/sda2 /mnt/recupero
  • Elencare i file recuperabili senza copiarli:

    sudo btrfs restore -l /dev/sda2

Recupero dei dati cancellati accidentalmente

Su Btrfs è possibile recuperare file cancellati in determinate circostanze grazie alla sua struttura interna e alle sue caratteristiche avanzate di gestione dei dati. Sebbene non offra direttamente un "livello di backup" come farebbe un sistema di backup tradizionale, alcune funzionalità del filesystem facilitano il recupero dei dati cancellati. Ragioni per cui è possibile recuperare un file cancellato su Btrfs:

Struttura a copy-on-write (CoW): Btrfs utilizza un modello copy-on-write (CoW), che significa che quando i dati vengono modificati, invece di sovrascrivere i blocchi esistenti, il filesystem crea nuovi blocchi per memorizzare i dati modificati. Questo lascia intatti i vecchi blocchi fino a quando non sono esplicitamente liberati.

Quando un file viene cancellato, i metadati vengono aggiornati per riflettere la cancellazione, ma i dati fisici sul disco non vengono immediatamente sovrascritti. Pertanto, è possibile recuperare i dati fino a quando quei blocchi non vengono sovrascritti da nuovi dati.

Strumenti di recupero: È possibile esplorare e recuperare i file tramite lo stesso btrfs restore, ma esistono script di terze parti creati da utenti della comunità che possono essere utilizzati per esplorare e recuperare file. Consulta la documentazione specifica su come utilizzarli.

Ulteriori risorse


CategoryHomepage CategoryNuoviDocumenti