# [BTRFS] Perte de mon /home (résolu)

## sebB

Bonjour,

Pour mon /home, et / j'utilise BTRFS.

Jusqu'à présent aucun soucis malgrés plusieurs hard reboot.

Cependant aujourd'hui, en me mattant un film, j'ai oublié de brancher l'alim de mon portable.

Et au redémarrage impossible de monter mon /home.

J'ai bien tenté avec un live cd mais je n'y ai pas accés.

Un mount /home ne donne rien

Un btrfsck donne

```
couldn't open because of unsupported option features (8)

btrfsck: disk-io.c:682: open_ctree_fd: Assertion '!(1)' failed.

Abandon
```

J'ai besoin de récupérer les données sur ce /home...

Merci

dmesg

http://pastebin.com/e16ttHyM

emerge --info

http://pastebin.com/ssG66r44

fstab

http://pastebin.com/CkC6aZ7r

/var/log/messages

http://pastebin.com/G48i8JmtLast edited by sebB on Thu Jul 28, 2011 9:06 pm; edited 2 times in total

----------

## Kazuya

Hello,

Tu utilises quel kernel ? 

Parce que là ton histoire c'est plutôt craignos, mais bon, tu étais au courant des risques... 

Quand je vois, encore dans le 2.6.39 : "Btrfs filesystem (EXPERIMENTAL) Unstable disk format"

Tu ne peux pas dire que tu n'as pas été prévenu... 

Pour moi, ça:

 *Quote:*   

> 
> 
> J'ai besoin de récupérer les données sur ce /home... 
> 
> 

 

et la ligne d'au dessus concernant le btrfs, c'est incompatible... 

Bon courage pour récupérer ton FS et tes données...

----------

## sebB

Salut,

kernel-2.6.38-r6

Avec le 2.6.39 pareil.

Là je suis en train de recompiler tout mon systeme, on ne sait jamais..

Quand j'essais de le monter avec un livecd ca me plante l'ordi avec un kernel panic.

----------

## Poussin

Comme a dit Kazuya, il y a peu de chance que tu récupères quelque chose.

Tu peux tester TestDisk, on ne sait jamais.

Quoiqu'il en soit, je te conseille d'abandonner ce FS pour des partitions critiques

----------

## guilc

 *sebB wrote:*   

> Là je suis en train de recompiler tout mon systeme, on ne sait jamais..

 

Recompiler le systeme ne réparera pas le FS corrompu !

BTRFS est instable, et pas encore mature. C'est pas pour rien que personne ne l'utilise par défaut et seulement pour des tests. Si btrfsck ne répare rien, tu peux tout simplement lui dire adieu, la recompilation est une perte de temps pure et simple !

Poussin : sauf que testdisk ne gère pas btrfs ! seulement les extX, FAT et NTFS ! Donc c'est aussi inutile...

Pour les données qui ont un minimum d'importance, il faut effectivement impérativement utiliser un FS plus mature et stable !

----------

## Poussin

Damn oui, il peut « retrouver une partition », j'ai lu trop vite. C'est foutu ^^

----------

## brubru

essaye photorec (dans le meme paquet testdisk) qui va scanner la partition à la recherche de fichier qu'il connaît,

mais je pense qu'il faut que les données soient rangées de façon simple (en un sel bloc, sans compression)

pour que ça marche bien.

l'erreur sur le btrfsck semble indiquer que l'outil est en retard sur le noyau (unsupported option features).

Et n'oublie pas de remonter le problème au devs de btrfs, tu as un joli kernel bug dans le dmesg au moment du mount il me semble,

C'est comme ça que tu auras le plus de chance de résoudre le pb.

----------

## sebB

J'ai tenté testdisk, phorotec, gparted...

Ce qui "me rassure" c'est que ma partition est bien visible et on voit le taux d'occupation, mais impossible de la monter

Pour btrfsck, j'ai installé la version git et effectivement je n'ai plus le meme message d'erreur.

```
Could not check mount status: Unknow error 104464744073709951614
```

J'ai effectivement fait un rapport de bogue aux devs btrfs.

Reste plus qu'a attendre.

Une lueur d'espoir avant le formatage.

----------

## fb99

si tu as de la place copie ta partitions ailleur avec dd (cf man dd), elle copie bit par bit et si un jour il y a un meilleur outil de réparation tu pourras ptre récupérer qqlch.

De toute façon quand on travail sur une partition avec des données sensibles ou pas c'est toujours mieux de la copier ainsi, tu travail toujours sans risque et tu peux toujours te permettre des erreurs de manipulations.

mes 0.002 cents.

PS: j'avais aussi récupérer des données sur partitions corrompus ainsi juste en le recopiant. bon courage.

----------

## geekounet

 *guilc wrote:*   

> Pour les données qui ont un minimum d'importance, il faut effectivement impérativement utiliser un FS plus mature et stable !

 

Ou faire un backup journalier  :Razz:  (et même avec un FS mature de toute façon).

----------

## boozo

 *geekounet wrote:*   

>  *guilc wrote:*   Pour les données qui ont un minimum d'importance, il faut effectivement impérativement utiliser un FS plus mature et stable ! 
> 
> Ou faire un backup journalier  (et même avec un FS mature de toute façon).

 

je confirme... ai fait les frais d'un ripage de doigts y'a pas très longtemps  :Laughing: 

Btw, dans son cas a supposer qu'un outils de récup puisse s'y coller "dans quelques années", vu le schéma d'organisation de ce fs... j'ai déjà mal au coeur rien que d'y penser...

----------

## sebB

Bon voilà, après 2 mois d'acharnement, j'ai ressorti mon disque dur du congélo et grace aux dev btrfs j'ai réussi à récupérer toutes les données.

Je ne mettrais pas la procédure car il y a beaucoup à dire mais si ca arrive à certains n'hésitez pas à leur exposer le problème, je les ai trouvé assez sympa.

Ce résolu m'évite une scène de ménage.

----------

## geekounet

Les backups peut sauver des couples.  :Wink: 

----------

## barul

Même si y'a beaucoup de choses à dire, ça aurait été très sympa de poster la solution, parce que là du coup le topic sert à rien, si un mec qui a le même problème tombe dessus, et qu'il voit un « Y'a plein de trucs à dire alors j'ai la flemme de mettre la solution. » ça va lui faire plaisir…

----------

## sebB

Voici la soluce déblayée.

En fait sur IRC on m'a fait faire pas mal de tests sans que je me rende compte qu'il ne fallait finalement pas grand chose.

Donc si ca vous arrive:

Noyau 2.6.38

```
kernel BUG at fs/btrfs/tree-log.c:820!
```

Upgrader au noyau 3.0

Vous aurez

```
kernel BUG at fs/btrfs/tree-log.c:1669!
```

Là c'est beaucoup plus parlant   :Very Happy: 

Explication:

 *Quote:*   

> This is because btrfs-progs does not update BTRFS_FEATURE_INCOMPAT_SUPP for
> 
> both lzo and mixed groups, you may go to btrfs-unstable source's ctree.h to
> 
> get real BTRFS_FEATURE_INCOMPAT_SUPP and update btrfs-progs side, then work
> ...

 

SOLUTION:

Télécharger la source git de btrfs-progs

```
git clone git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-progs-unstable.git
```

Appliquer ce patch

https://patchwork.kernel.org/patch/266252/

Ensuite 

```
make && make install

make btrfs-zero-log

```

Et la commande miracle :

```
./btrfs-zero-log /dev/sdb1
```

Et là il ne vous reste plus qu'à dire à Mademoiselle: tu vois bien que je les avaient bien conservées les photos du mariage de ta copine, tu t'énerve pour un rien!!

 *geekounet wrote:*   

> Les backups peut sauver des couples.

 

Je m'en suis fait un joli fond d'écran

EDIT: Merci à fb99 pour l'idée du dd car je n'y avait pas pensé et ca m'avait permis de pouvoir réinstaller en ayant copié la partition corrompue sur un autre disque.

----------

## Enlight

<troll>

BTRFS est _instable_ ET _LENT_, sans déconner pourquoi vous l'utilisez????

</troll>

Après réflexion peut-on parler de troll quand les faits sont avérés???

----------

## xaviermiller

Attendons que BTRFS soit le filesystem par défaut de Fedora. Ils ont postposé son arrivée en standard à cause du manque d'outils de réparation...

----------

## barul

BTW, désolé si je pollue le topic, mais j'ai testé Fedora 16 sur mon laptop, ça tournait assez bien, plutôt rapide même (en liveusb, le spin XFCE).

----------

## Enlight

Je dirais que rien n'est moins sur que le fait que btrfs devienne le FS par defaut de Fedora dans la mesure où les tests menés par redhat montre qu'ext4 et xfs sont plus performants depuis l'élimination de gros bottleneck (lazy inode intialization pour ext4 et delayed logging pour xfs) en plus d'être plus matures. (et que les principaux devs de ces FS bossent chez redhat)

----------

## xaviermiller

Pour le moment, le passage à BTRFS est posposé au plus tôt à Fedora 17 : http://www.phoronix.com/scan.php?page=news_item&px=OTc2OA

----------

## d2_racing

Je sais que le gestionnaire de package de Fedora(Yum) va inclure automatiquement des snapshots avant chaque maj.

Je suis certain que la gang de Zac Medico vont sûrement regarder ça du coin de l'oeil et peut-être essayer de coder ce principe dans Portage, qui sait  :Razz: 

----------

## geekounet

Ce n'est pas nouveau comme méthode, (Open)Solaris fait des snapshots ZFS avant chaque update.  :Wink: 

----------

