Como faço para corrigir btrfs? [fechadas]

Pesquisei listas de discussão e finalmente terminei na página do Ubuntubtrfs , e sinto-me que btrfs ainda não possui um utilitário de correção completa (como indicado na página inicial ). Mesmo meses atrás, ele era o padrão para o Linux da Oracle e está incluído em muitas distribuições.

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

Caso contrário, a cópia dos meus backups por cima do meu FS corrigirá as coisas? (Ao excluir instantâneos, se necessário, por espaço? Ou para excluir corrupção?) Em vez disso, devo tentar reverter para um instantâneo anterior e restaurar os arquivos ausentes do backup? Ou restaurar os arquivos ausentes dos meus instantâneos @ e @home?

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

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

Desliguei durante um desligamento interrompido e, por isso, fui apresentado com instabilidade do sistema. O sistema será inicializado e executado por um certo período de tempo até gravar dados suficientes e congelar. A última vez que acabei de abrir o Thunderbird. Isso requer redefinições mais rígidas e presumivelmente mais corrupção. sudo btrfsck /dev/sda1oscila entre alguns erros - geralmente a 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 é getty realmente frutado (eu só esperava ver parent transid verify failedaqui ...)

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; eu nunca quis sobrecarregá-lo com esses detalhes :))

E agora minha execução final me deixa com o 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 alegria feliz. Observe que isso verify failedmuda conforme os dados são gravados na unidade.

Outro erro aleatório:

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

Para ajudar na resposta:

a verificação de transferência pai falhou em 14265458688 desejado 464230 encontrado 464221

Pode ser reparado com:

$ btrfs-zero-log DEVICE

NOTA: os dados podem ser perdidos! Primeiro tente montar com:

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

Se não é possível montar dados como diz "bad fs":

$ btrfs restore DEVICE DIRECTORY_TO_DUMP_DATA_TO

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

trecho de e-mail

Re: Pergunta: Como posso recuperar esta partição? (não foi possível encontrar o $ hugenum lógico len 4096)

Hugo Mills carfax.org.uk> escreve:

Em segunda-feira, 26 de agosto de 2013 às 01:10:54 PM -0600, Chris Murphy escreveu:

Em 26 de agosto de 2013, às 11:41, Nick Lee nickle.es> escreveu:

Houve uma discussão no IRC, há alguns dias, que o problema com o bloco da raiz da árvore era provavelmente o resultado de um problema no próprio disco ou dos mapeamentos de árvore de blocos / lógicos. Executei a recuperação do pedaço, examinei os erros encontrados e pressionei write. (Se falhasse, eu executaria algo photorec, perda de organização como efeito colateral.)

Posso escrever algo mais claro depois que meu voo aterrar amanhã, se você quiser.

Estou curioso para saber quando usar várias técnicas: -o recovery, btrfsck, chunk-recover, zero log.

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

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

Comece com -orecovery e -oro, recovery para praticamente qualquer coisa.

Se isso falhar, procure no dmesg erros relacionados à árvore de logs - se isso estiver corrompido e não puder ser lido (ou causar uma falha), use btrfs-zero-log.

Se houver problemas com a árvore de fragmentos - o único que eu vi recentemente relatando algo como "não é possível mapear o endereço" -, então o fragmento de recuperação pode ser útil.

Depois disso, o btrfsck é provavelmente a próxima coisa a tentar. Se as opções -s1, -s2, -s3 tiverem êxito, o btrfs-select-super ajudará substituindo o superbloco por um que funcione. Se isso não for útil, volte ao btrfsck --repair.

Finalmente, o btrfsck --repair --init-extension-tree pode ser necessário se houver uma árvore de extensões danificada. Finalmente, se você tem corrupção nas somas de verificação, há --init-csum-tree.

Hugo.