Come riparo btrfs? [chiuso]

Ho passato in rassegna le mailing list e finalmente ho finito sulla pagina di Ubuntubtrfs , e mi rimane la sensazione che non abbia btrfs ancora un'utilità di correzione completa (come indicato sulla loro home page ). Anche se mesi fa è stato programmato come predefinito per Oracle Linux ed è incluso in molte distro.

Quindi, al posto di ciò, esiste una guida alla risoluzione dei problemi da qualche parte su come risolvere btrfs?

In caso contrario, la copia dei miei backup nella parte superiore del mio FS risolverà le cose? (Durante l'eliminazione delle istantanee se necessario per lo spazio? O per eliminare la corruzione?) Dovrei invece provare a ripristinare un'istantanea precedente e quindi ripristinare i file mancanti dal backup? O ripristinare i file mancanti dalle mie istantanee @ e @home?

Nota : questa è una domanda generale. Ho deliberatamente omesso i miei esatti problemi di FS (per il momento); Voglio trovare un flusso di lavoro generale / canonico e una guida alla risoluzione dei problemi.

(Ok, ok - ecco alcuni ulteriori dettagli;)) :

Mi sono spento durante uno spegnimento sospeso e, di conseguenza, mi è stata presentata l'instabilità del sistema. Il sistema si avvierà e funzionerà per un certo periodo di tempo fino a quando non scrive abbastanza dati e si blocca. L'ultima volta che ho appena aperto Thunderbird. Questi richiedono reimpostazioni più rigide e presumibilmente più corruzione. sudo btrfsck /dev/sda1oscilla tra alcuni errori, spesso la prima volta del modulo

root 338 inode 7861227 errors 1000
root 338 inode 7904568 errors 1000
root 338 inode 7955174 errors 400
found 46242054144 bytes used err is 1
total csum bytes: 43112400
total tree bytes: 2074640384
total fs tree bytes: 1889853440
btree space waste bytes: 547680627
file data blocks allocated: 110756974592
 referenced 68393684992
Btrfs Btrfs v0.19

oooo, ora è getty davvero fruttato (mi aspettavo solo di vedere parent transid verify failedqui ...)

parent transid verify failed on 14266105856 wanted 464223 found 464221
parent transid verify failed on 14266105856 wanted 464223 found 464221
Extent back ref already exists for 14261530624 parent 0 root 256 
leaf parent key incorrect 14261751808
bad block 14261751808
Extent back ref already exists for 66455355392 parent 0 root 2 
Extent back ref already exists for 66455257088 parent 0 root 2 
Extent back ref already exists for 14257274880 parent 0 root 2 
block 14262571008 rec extent_item_refs 2, passed 2
block 14262575104 rec extent_item_refs 1, passed 1
block 14262579200 rec extent_item_refs 1, passed 1
Extent back ref already exists for 14262579200 parent 0 root 257 
leaf 14263906304 items 50 free space 132 generation 464224 owner 2
fs uuid 7d049403-cf6e-4b52-a624-32051e1f5b2a
chunk uuid be6f8f93-320c-4465-85d6-f53907698c32
item 0 key (14263341056 EXTENT_ITEM 4096) itemoff 3944 itemsize 51
    extent refs 1 gen 464168 flags 2
    tree block key (8332576 1 0) level 0
    tree block backref root 257
item 1 key (14263345152 EXTENT_ITEM 4096) itemoff 3893 itemsize 51
    extent refs 1 gen 464168 flags 2
    tree block key (8332586 c 8332543) level 0
    tree block backref root 257
failed to find block number 14263525376

(Tutto sommato pesantemente ovviamente; non ho mai voluto sopraffarti con questi dettagli :))

E ora la mia esecuzione finale mi lascia con il familiare:

parent transid verify failed on 14265458688 wanted 464230 found 464221
parent transid verify failed on 14265458688 wanted 464230 found 464221
parent transid verify failed on 14265458688 wanted 464230 found 464223
btrfsck: root-tree.c:46: btrfs_find_last_root: Assertion `!(path->slots[0] == 0)' failed.

, incluso l'errore casuale facoltativo alla fine. Oh gioia felice. Si noti che queste verify failedmodifiche cambiano quando i dati vengono scritti sull'unità.

Un altro errore casuale:

btrfsck: disk-io.c:412: find_and_setup_root: Assertion `!(!root->node)' failed.

Per aiutare con la risposta:

verifica transid padre non riuscita su 14265458688 ricercato 464230 trovato 464221

Può essere riparato con:

$ btrfs-zero-log DEVICE

NOTA: i dati possono andare persi! Prima prova e monta con:

$ mount -t btrfs -o recovery,nospace_cache,clear_cache DEVICE MOUNTPOINT

Se non riesco a montare i dati come dice "bad fs":

$ btrfs restore DEVICE DIRECTORY_TO_DUMP_DATA_TO

Ecco una vera e-mail, sebbene difficile da seguire, che ho inviato per chiarire la sua soluzione. Spero che tu possa capire questa spiegazione criptica:

estratto di e-mail

Ri: Domanda: Come posso recuperare questa partizione? (impossibile trovare $ hugenum logico 4096)

Hugo Mills carfax.org.uk> scrive:

Il lunedì 26 agosto 2013 alle 13:10:06 PM -0600, Chris Murphy ha scritto:

Il 26 agosto 2013, alle 11:41, Nick Lee nickle.es> ha scritto:

Alcuni giorni fa è stata discussa l'IRC che il problema con il bloco della radice dell'albero era probabilmente il risultato di un problema con il disco stesso o dei blocchi di albero / mappature logiche. Ho eseguito il recupero del blocco, ho esaminato gli errori rilevati e ho premuto write. (Se falliva, avrei eseguito qualcosa di photorec, perdita di organizzazione come effetto collaterale.)

Posso scrivere qualcosa di più chiaro dopo che il mio volo atterrerà domani, se vuoi.

Sono solo curioso di sapere quando usare varie tecniche: -o recovery, btrfsck, chunk-recover, zero log.

Supponiamo che tu non abbia un guasto fisico del dispositivo (che è un diverso set di strumenti - mount -odegraded, btrfs dev del missing).

La prima cosa da fare è prendere un btrfs-image -c9 -t4 del filesystem e conservare una copia dell'output per mostrare josef. :)

Quindi inizia con -orecovery e -oro, recupero praticamente per qualsiasi cosa.

Se falliscono, cerca in dmesg gli errori relativi all'albero dei registri - se è corrotto e non può essere letto (o provoca un arresto anomalo), usa btrfs-zero-log.

Se ci sono problemi con l'albero dei blocchi - l'unico che ho visto di recente è stato segnalare qualcosa come "impossibile mappare l'indirizzo" - potrebbe essere utile usare il blocco dei blocchi.

Dopodiché, probabilmente btrfsck è la prossima cosa da provare. Se le opzioni -s1, -s2, -s3 hanno qualche successo, allora btrfs-select-super aiuterà a sostituire il superblocco con uno che funziona. Se questo non sarà utile, torna a btrfsck --repair.

Infine, btrfsck --repair --init-extension-tree potrebbe essere necessario se c'è un albero di estensione danneggiato. Infine, se hai corruzione nei checksum, c'è --init-csum-tree.

Hugo.