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.