Como corrijo o btrfs? [fechadas]

Question

Eu vasculhei listas de discussão e finalmente terminei em btrfs page do Ubuntu , e estou sentindo que btrfs ainda não tem um utilitário de conserto completo (como indicado na página inicial ) . Apesar de meses atrás, ele foi programado para ser o padrão para o Linux da Oracle e está incluído em muitas distribuições.

Então, em vez disso, há um guia de solução de problemas em algum lugar sobre como corrigir btrfs ?

Se isso falhar, copiar meus backups no topo do meu FS corrigirá as coisas? (Ao excluir instantâneos, se necessário para o espaço? Ou para apagar a corrupção?) Devo, em vez disso, tentar reverter para um instantâneo anterior e restaurar os arquivos ausentes do backup? Ou restaurar arquivos ausentes dos meus instantâneos @ e @home?

Nota : esta é uma pergunta geral. Eu deliberadamente omiti meus problemas exatos do FS (no momento); Desejo encontrar um fluxo de trabalho geral / canônico e um guia de solução de problemas.

(Ok, ok - aqui estão alguns detalhes mais ;)) :

Eu desliguei durante um desligamento suspenso e recebi a instabilidade do sistema. O sistema será inicializado e executado por algum tempo até que ele grave dados suficientes e congele. Na última vez, acabei de abrir o Thunderbird. Estes requerem mais reinicializações de disco rígido e presumivelmente mais corrupção. sudo btrfsck /dev/sda1 oscila entre alguns erros - geralmente na primeira vez do formulário

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, agora é o getty realmente frutado (eu só esperava ver parent transid verify failed aqui ...)

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

(Tudo muito resumido, é claro; nunca quis sobrecarregar você com esses detalhes:))

E agora minha execução final me deixa familiar:

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.

, incluindo o erro aleatório opcional no final. Oh feliz alegria. Observe que esses verify failed são alterados à medida que os dados são gravados na unidade.

Outro erro aleatório:

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

    

Answer 1

Para ajudar com a resposta:

parent transid verify failed on 14265458688 wanted 464230 found 464221

Pode ser corrigido com:

$ btrfs-zero-log DEVICE

NOTA: os dados podem ser perdidos! Primeiro tente e monte com:

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

Se não puder montar dados como se fosse "bad fs":

$ btrfs restore DEVICE DIRECTORY_TO_DUMP_DATA_TO

Aqui está um e-mail real, embora difícil de seguir, enviado para esclarecer sua solução. Espero que você possa entender esta explicação enigmática:

trecho e-mail

Re: Question: How can I recover this partition? (unable to find logical $hugenum len 4096)

Hugo Mills carfax.org.uk> writes:

On Mon, Aug 26, 2013 at 01:10:54PM -0600, Chris Murphy wrote:

On Aug 26, 2013, at 11:41 AM, Nick Lee nickle.es> wrote:

There was a discussion on IRC a few days ago that the problem with the tree root's bloco was likely the result of either an issue with the disk itself, or the chunk tree/logical mappings. I ran the chunk recover, looked over the errors it found, and hit write. (If it failed, I was going to run something photorec, loss of organization as a side effect.)

I can write something more clear after my flight lands tomorrow if you want.

         

Estou apenas curioso sobre quando usar várias técnicas: -o recuperação,     btrfsck, chunk-recover, zero log.

  

     

Vamos supor que você não tenha uma falha no dispositivo físico (o que   é um conjunto diferente de ferramentas - mount -odegraded, btrfs dev del   ausente).

     

A primeira coisa a fazer é pegar uma imagem btrfs -c9-t4 do   sistema de arquivos, e mantenha uma cópia da saída para mostrar josef. :)

     

Então comece com -orecovery e -oro, recuperação para praticamente   qualquer coisa.

     

Se eles falharem, procure no dmesg os erros relacionados ao log   árvore - se isso é corrupto e não pode ser lido (ou causa uma falha), use   btrfs-zero-log.

     

Se houver problemas com a árvore de blocos - a única que vi   recentemente estava relatando algo como "não pode mapear endereço" - então   chunk-recover pode ser útil.

     

Depois disso, o btrfsck é provavelmente a próxima coisa a tentar. Se as opções   -s1, -s2, -s3 tem algum sucesso, então o btrfs-select-super ajudará   substituindo o superbloco por um que funcione. Se isso não vai   seja útil, volte para o btrfsck --repair.

     

Finalmente, btrfsck --repair --init-extent-tree pode ser necessário se   há uma árvore de extensão danificada. Finalmente, se você tem corrupção   as somas de verificação, há --in-csum-tree.

     

Hugo.