Comment réparer btrfs? [fermé]

J'ai parcouru les listes de diffusion et j'ai finalement fini sur la btrfspage d'Ubuntu , et j'ai le sentiment qu'il n'a btrfs toujours pas d'utilitaire de correction complet (comme indiqué sur leur page d'accueil ). Même s'il y a des mois, il était prévu d'être la valeur par défaut pour Linux d'Oracle et est inclus dans de nombreuses distributions.

Donc, au lieu de cela, y a-t-il un guide de dépannage quelque part sur la façon de réparer btrfs?

À défaut, la copie de mes sauvegardes par-dessus mon FS réparera-t-elle les choses? (Lors de la suppression d'instantanés si nécessaire pour l'espace? Ou pour supprimer la corruption?) Dois-je plutôt essayer de revenir à un instantané précédent, puis restaurer les fichiers manquants à partir de la sauvegarde? Ou restaurer les fichiers manquants de mes instantanés @ et @home?

Remarque : Il s'agit d'une question générale. J'ai délibérément omis mes problèmes exacts de FS (pour le moment); Je veux trouver un flux de travail général / canonique et un guide de dépannage.

(Ok, ok - voici quelques plus de détails;)) :

Je me suis éteint lors d'un arrêt bloqué et j'ai donc été confronté à une instabilité du système. Le système démarre et s'exécute pendant un certain temps jusqu'à ce qu'il écrit suffisamment de données et se fige. La dernière fois, je venais d'ouvrir Thunderbird. Ceux-ci nécessitent des réinitialisations plus dures et vraisemblablement plus de corruption. sudo btrfsck /dev/sda1oscille entre quelques erreurs - souvent la première fois du formulaire

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, maintenant c'est vraiment vraiment fruité (je m'attendais seulement à voir parent transid verify failedici ...)

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

(Tous bien résumés bien sûr; je n'ai jamais voulu vous submerger de ces détails :))

Et maintenant, ma dernière exécution me laisse avec le familier:

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.

, y compris l'erreur aléatoire facultative à la fin. Oh joie heureuse. Notez que ceux-ci verify failedchangent à mesure que les données sont écrites sur le lecteur.

Une autre erreur aléatoire:

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

Pour aider à répondre:

échec de la vérification du parent transid sur 14265458688 recherché 464230 trouvé 464221

Peut être fixé avec:

$ btrfs-zero-log DEVICE

REMARQUE: les données peuvent être perdues! Essayez d'abord de monter avec:

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

Si vous ne pouvez pas monter de données comme cela dit "mauvais fs":

$ btrfs restore DEVICE DIRECTORY_TO_DUMP_DATA_TO

Voici un véritable email, bien que difficile à suivre, que j'ai envoyé pour clarifier sa solution. J'espère que vous pourrez comprendre cette explication cryptique:

extrait d' email

Re: Question: Comment puis-je récupérer cette partition? (impossible de trouver $ hugenum logique len 4096)

Hugo Mills carfax.org.uk> écrit:

Le lundi 26 août 2013 à 13 h 10 min 54 s -0600, Chris Murphy a écrit:

Le 26 août 2013, à 11 h 41, Nick Lee nickle.es> a écrit:

Il y a quelques jours, il y a eu une discussion sur IRC selon laquelle le problème avec le bloco de la racine de l'arborescence était probablement le résultat d'un problème avec le disque lui-même, ou avec l'arborescence en morceaux / les mappages logiques. J'ai exécuté la récupération de morceau, j'ai examiné les erreurs trouvées et j'ai appuyé sur écriture. (Si cela échouait, j'allais exécuter quelque chose de photorec, une perte d'organisation comme effet secondaire.)

Je peux écrire quelque chose de plus clair après mon vol demain si vous le souhaitez.

Je suis simplement curieux de savoir quand utiliser différentes techniques: -o recovery, btrfsck, chunk-restore, zero log.

Supposons que vous n'ayez pas de panne de périphérique physique (qui est un ensemble d'outils différent - montage-dégradé, btrfs dev del missing).

La première chose à faire est de prendre une image btrfs -c9 -t4 du système de fichiers, et de conserver une copie de la sortie pour montrer josef. :)

Commencez ensuite par -orecovery et -oro, récupération pour à peu près tout.

Si ceux-ci échouent, recherchez dans dmesg les erreurs relatives à l'arborescence des journaux - si cela est corrompu et ne peut pas être lu (ou provoque un crash), utilisez btrfs-zero-log.

S'il y a des problèmes avec l'arbre de morceaux - le seul que j'ai vu récemment signalait quelque chose comme "impossible de mapper l'adresse" - alors la récupération de morceaux peut être utile.

Après cela, btrfsck est probablement la prochaine chose à essayer. Si les options -s1, -s2, -s3 réussissent, alors btrfs-select-super vous aidera en remplaçant le superbloc par un qui fonctionne. Si cela ne vous sera pas utile, revenez à btrfsck --repair.

Enfin, btrfsck --repair --init-extend-tree peut être nécessaire s'il y a un arbre d'extension endommagé. Enfin, si vous avez de la corruption dans les sommes de contrôle, il y a --init-csum-tree.

Hugo.