Forum Linux.debian/ubuntu Encore un problème avec BRTFS

Posté par  . Licence CC By‑SA.
Étiquettes :
7
21
fév.
2024

Bonjour, j'ai un petit soucis avec un de mes disque dur formaté en BRTS
du jour au lendemain impossible de le monter ni effectuer les commandes de réparation.
Je comptais sur la commande btrfs restore pour extraire mes données sur un second disque et reformater le premier mais même cette commande qui pourtant m'a sauvé une fois (j'avais posté ici d'ailleurs) ne fonctionne pas sur ce coup !

Voici le topo :
Disque de 6To en parfaite condition de santé matériel (Crystal Disk :100% et HD SENTINEL aussi)
pas de secteurs défectueux.
Les superblocks sont bons

Le disque est remplis à hauteur de 5 To sur les 6To
L'erreur visiblement est celle-ci : ERROR: root [5 0] level 0 does not match 2__

Pour les sorties complètes :

sudo btrfs restore -i /dev/sda1 /dev/sdb1

    parent transid verify failed on 274579456 wanted 67934 found 67931
    parent transid verify failed on 274579456 wanted 67934 found 67931
    parent transid verify failed on 274579456 wanted 67934 found 67931
    Ignoring transid failure
    ERROR: root [5 0] level 0 does not match 2

    Could not open root, trying backup super

sudo btrfs check --repair --force --init-csum-tree --init-extent-tree --check-data-csum --clear-ino-cache -p /dev/sda1

enabling repair mode
Creating a new CRC tree
Opening filesystem to check...
parent transid verify failed on 274579456 wanted 67934 found 67931
parent transid verify failed on 274579456 wanted 67934 found 67931
parent transid verify failed on 274579456 wanted 67934 found 67931
Ignoring transid failure
ERROR: root [5 0] level 0 does not match 2

ERROR: cannot open file system

Si quelqu'un peux m'aider, la je sèche
merci

  • # Acessing a Btrfs partition wich is superblock has been deleted

    Posté par  . Évalué à 3 (+1/-0).

    tu peux expérimenter avec ce qui est écrit ici : https://www.reddit.com/r/btrfs/comments/18r7ff4/acessing_a_btrfs_partition_wich_is_superblock_has/

  • # résolu

    Posté par  . Évalué à 6 (+5/-0). Dernière modification le 26 février 2024 à 15:06.

    Bon j'ai pu trouver comment exécuter un btrfs restore, je donne la soluce :

    j'ai d’abords cherché des blocks valides pour pouvoir lire l’arborescence du FS avec :

    sudo btrfs-find-root /dev/sdb1

    parent transid verify failed on 274579456 wanted 67934 found 67931
    parent transid verify failed on 274579456 wanted 67934 found 67931
    Superblock thinks the generation is 67934
    Superblock thinks the level is 0
    Found tree root at 447201280 gen 67934 level 0
    Well block 150192128(gen: 67933 level: 0) seems good, but generation/level doesn't match, want gen: 67934 level: 0
    Well block 88375296**(gen: 67932 level: 0) seems good, but generation/level doesn't match, want gen: 67934 level: 0

    Puis j'ai lancé sudo btrfs restore -t 150192128 /dev/sdb1 /media/linux/DATA2

    j'ai choisis le premier block valide sur les deux trouvés par
    btrfs-find-root

    -Well block 150192128 et Well block 88375296

    ça semble fonctionner pour l'instant, mes données sont en train d’être copiées sur un autre HDD

    • [^] # Re: résolu

      Posté par  . Évalué à 5 (+3/-0).

      merci et bravo pour le retour ; voici ce que j'ai sur mon NAS avec des warning un peu similaires.

      # btrfs-find-root /dev/sdb1
Superblock thinks the generation is 385646
Superblock thinks the level is 0
Found tree root at 39075840 gen 385646 level 0
Well block 38797312(gen: 385645 level: 0) seems good, but generation/level doesn't match, want gen: 385646 level: 0

      • [^] # Re: résolu

        Posté par  . Évalué à 6 (+5/-0).

        Merci mais j'ai trouvé sur un forum, je ne suis pas assez calé sur ce FS pour avoir déduit moi-même …
        tu as le même message visiblement,je ne sais pas si tu peux monter ton disque ou si tu est bloqué comme moi mais au moins en dernier recours on peux extraire nos données tant qu'il y a une superblock valide..
        perso j’arrête BRTFS et je passe en EXT4
        je pense que ce FS est très bien pour du Raid mais pour un usage classique c'est encore trop expérimental et mine de rien je n'ai jamais eu de probleme avec l'Ext4.J'ai essayé brtfs pendant 6 ans pour mes stockages et j'ai été *** tous les 8 mois.

        • [^] # Re: résolu

          Posté par  . Évalué à 3 (+1/-0).

          pour ce qui me concerne avec BTRFS :
          - RAS a titre perso, sur un NAS avec 3 disques partitionnés et 2 types de RAID (5 et JBOD)
          - un incident sur un serveur de backup en 5 ans environ ; il héberge 150To de données. Nous avons fait au plus simple : formatage et resynchro des données.

          J'ai aussi des VM qui ont des partitions ou disques virtuels en BTRFS sans incident ; j'avais créé des volumes BTRFS pour la fonction snapshot, avant d'en disposer sur infra de virtualisation Proxmox + CEPH.

          • [^] # Re: résolu

            Posté par  . Évalué à 4 (+3/-0).

            d'accords donc j'ai juste pas eu de chance car j'ai utilisé ce FS à titre domestique pour le stockage de mes archives (8To + 8To en backup) et j'ai eu un incident environ tous les 8-12 mois, j'ai pu tout récupérer à chaque fois mais la perte de temps additionné est colossal, il faut 30h pour réup 8TO avec brtfs restore.

            • [^] # Re: résolu

              Posté par  . Évalué à 3 (+1/-0). Dernière modification le 23 février 2024 à 20:40.

              Je ne sais pas du tout si la taille du FS augmente ou pas la probabilité d'avoir un problème avec BTRFS (et si c'était le cas, ça ne serait évidemment pas une excuse) mais il va sans dire que ton usage "domestique" est très largement au dessus de la moyenne.

              Personnellement j'ai 2 ou 3 To en raid1 et je fais régulièrement (mensuellement ou beaucoup plus rarement après un arrêt "brutal" comme une coupure secteur ou un reset hardware suite à un crash du système) des btrfs device stat et des scrub. Je ne sais pas si c'est à cause de cette maintenance régulière ou bien par chance mais je n'ai jamais eu de problème bloquant mon FS (hors panne disque). En revanche, les snapshots m'ont 2 ou 3 fois sauvé la mise suite à une mise à jour problématique.

              Et comme j'ai des backups je n'ai vu jusqu'à présent aucune raison de revenir sur ce choix.

              Ceci dit, tes problèmes récurrents interpellent quand même.

          • [^] # Re: résolu

            Posté par  . Évalué à 5 (+3/-0).

            Aussi, sur les NAS Synology, c'est du BTRS par défaut. J'ai travaillé quelques mois avec une dizaine de serveurs Syno à 300+To en RAID6, ça se comporte plutôt bien je dois dire.

            Ceci dit, les versions sont validées par l'éditeur, les disques durs sont de qualité (SATA mais haut de gamme), et la RAM fait de la correction d'erreur (ECC). J'imagine que rien que la RAM ECC ça joue pas mal sur la fiabilité.

            Après, globalement, ZFS fonctionne bien aussi, XFS aussi… Mais au final EXT4 s'en sort bien également et est tellement plus testé que pour un usage de base, je ne vois pas l'intérêt d'utiliser autre chose.

            • [^] # Re: résolu

              Posté par  . Évalué à 4 (+3/-0).

              J'en suis arrivé au même constat, c’est sûrement un solide FS en environnement contrôlé mais pour le perso domestique de base vaut mieux un autre.Ext4 est éprouvé,d’ailleurs peut être un jour brtfs lui succedera qui sait..

              • [^] # Re: résolu

                Posté par  . Évalué à 2 (+0/-0).

                La compression des données peut être utile, même dans le cadre d'une utilisation personnelle.

                • [^] # Re: résolu

                  Posté par  . Évalué à 4 (+2/-0). Dernière modification le 25 février 2024 à 20:59.

                  Oui, complètement ! La compression est vraiement un truc qui manque à ext4.

                  Ce qu'on veut dire, c'est que BTRFS, comme ZFS, n'est pas forcément adapté sur du matériel grand public. Les docs de ZFS disent que sans ECC, c'est une très mauvaise idée, et BTRFS suggère que c'est utile.

                  • [^] # Re: résolu

                    Posté par  . Évalué à 2 (+1/-0).

                    Merci pour ces précisions, je suis d'accords, btrfs est excellent dans le bon setup hardware, pour l'ECC je n'avais pas vu a l'epoque sinon j'aurais acheté cette Ram mais bon trop tard je suis passé sur Ext4 et pour la compression je ne m'en sert pas de toute facon.

                  • [^] # Re: résolu

                    Posté par  . Évalué à 4 (+2/-0). Dernière modification le 26 février 2024 à 09:32.

                    Les docs de ZFS disent que sans ECC, c'est une très mauvaise idée, et BTRFS suggère que c'est utile.

                    Cette phrase laisse penser que ECC est utile dans le cas de BTRFS. Or, l'explication donné dans le lien est que c'est utile indépendamment du FS considéré. Et je dirais même que ce serait plus utile pour EXT4 que pour BTRFS car ce dernier intègre un mécanisme de détection d'erreur et, mieux encore, un mécanisme de correction d'erreur si on est en raid (NB. BTRFS permet de faire du raid même avec un seul disque ; ça ne protégera évidement pas des pannes hardware mais ça permet la détection et correction d'erreur).

                    Si on y ajoute la fonctionnalité snapshot qui permet de revenir en arrière très simplement et rapidement en cas de mise à jour d'OS problématique (par exemple si on utilise une distribution en rolling release), moi c'est au contraire BTRFS que j'installe sur les PC de mon entourage.

                    Dire que ce n'est pas adapté sur du matériel grand public me paraît une affirmation un peu péremptoire au vu des arguments avancés.

                    • [^] # Re: résolu

                      Posté par  . Évalué à 3 (+1/-0).

                      Et je dirais même que ce serait plus utile pour EXT4 que pour BTRFS car ce dernier intègre un mécanisme de détection d'erreur […].

                      Je me corrige moi-même : j'ai confondu le bit flip en mémoire dont parle le lien et celui qui peut arriver sur un disque (parfois appelé bitrot). J'ignore si BTRFS est réellement plus vulnérable au bit flip que EXT4 (plus de données décrivant le FS en mémoire ?) mais en ce qui concerne le bitrot ou la corruption du disque, il n'y a pas photo, il offre les outils pour s'en prémunir, contrairement à EXT4.

                      Pour ZFS, je crois avoir lu que c'est parce que son cache mémoire est gigantesque (il essaie de prendre toute la mémoire disponible), ce qui augmente la probabilité qu'un éventuel bit flip se situe dedans.

                      • [^] # Re: résolu

                        Posté par  (site web personnel) . Évalué à 6 (+4/-0). Dernière modification le 26 février 2024 à 18:33.

                        Pour ZFS, je crois avoir lu que c'est parce que son cache mémoire est gigantesque (il essaie de prendre toute la mémoire disponible)

                        ah, mais tu n'as pas besoin de le croire : c'est comme ça qu'Oracle fourguait ses Solaris avec genre 96 Go de RAM par LDOM pour héberger 5 pauvres bases de données et faire croire que leurs perfs étaient au top => forcément avec presque tout chargé en mémoire, même avec les pires requêtes (qui — au hasard — faisaient des FULL /o\) ça ne ramait pas trop :/ et — en plus — ils se mettaient dans la poche les admin' sys qui — voyant la conso RAM dépassant la moitié de la RAM physique allouée — préconisaient de l'augmenter encore o_O tout ça pour que ZFS ait plus de cache à consommer…

                        • [^] # Re: résolu

                          Posté par  . Évalué à 2 (+0/-0).

                          Si je puis me permettre, prendre la RAM dispo pour faire du cache disque, c'est le comportement par défaut de Linux, et quand tu fais beaucoup de lectures (sur un NAS, par exemple), ça peut occuper toute la RAM dispo comme cache (la colonne buff/cache dans free).

                          Simplement sur ZFS ça se voit plus car la RAM est allouée à un thread nommée zfs_quelquechose, et de manière un poil plus aggressive.

                          Mais globalement c'est kif-kif bourricot entre ZFS et d'autres FS sur un serveur occupé à faire des E/S disques.

                          Par exemple sur ma machine qui ne fout rien, j'ai déjà 1.7Gio de cache, avec ext4 :

                          ~ $ free -h
               total        used        free      shared  buff/cache   available
Mem:           7.7Gi       1.2Gi       5.1Gi       109Mi       1.7Gi       6.5Gi

                          Alors sur un serveur qui travaille…

                          • [^] # Re: résolu

                            Posté par  . Évalué à 2 (+0/-0).

                            De ce que j'avais compris de mes lectures, ZFS a besoin de (beaucoup) plus de mémoire pour fonctionner avec des perfs normales. Ce n'est pas juste qu'il utilise la mémoire disponible "tant qu'à faire puisqu'il y en a".

                            Ceci dit, c'est un peu HS, j'essayais juste de proposer une explication au pourquoi ECC était lourdement préconisé pour ZFS.

                            • [^] # Re: résolu

                              Posté par  . Évalué à 4 (+2/-0).

                              D'ailleurs je te rejoins sur le fait que probablement tous les systèmes de fichier profitent de la RAM ECC (Linus Torvalds avait taclé Intel sur la non-généralisation de l'ECC il y a quelques temps).

                              Quitte à enfoncer une porte ouverte, pouvoir mettre en cache à tous les étages est la clé de la performance, que ce soit très bas niveau dans du cache CPU ou très haut niveau comme un proxy web ou un CDN.

  • # Bart filesystem ?

    Posté par  (site web personnel) . Évalué à 5 (+3/-0).

    BRTFS, c'est quoi ? Le système de fichier de Bart Simpson ?

    Dans ce cas, c'est pas étonnant qu'il soit instable, non ?

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.