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 Marc Quinton . Évalué à 3.
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/
[^] # Re: Acessing a Btrfs partition wich is superblock has been deleted
Posté par jeremyb14 . Évalué à 2.
Merci, j'ai testé les commandes suggérées dans ce post reddit :
-sudo btrfs rescue super-recover /dev/sdb1
All supers are valid, no need to recover
-sudo mount -o rescue=usebackuproot /dev/sdb1 /mnt
mount: /mnt: impossible de lire le superbloc à l’adresse /dev/sdb1.
[^] # Re: Acessing a Btrfs partition wich is superblock has been deleted
Posté par jeremyb14 . Évalué à 1.
j'ai lancé un btrfs rescue chunk-recover pour voir ce que ça donne
le btrfs rescue zero-log /dev/sdb1 donne :
```
parent transid verify failed on 274579456 wanted 67934 found 67931
parent transid verify failed on 274579456 wanted 67934 found 67931
ERROR: could not open ctree
```
# résolu
Posté par jeremyb14 . Évalué à 6. 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 :
Puis j'ai lancé
sudo btrfs restore -t 150192128 /dev/sdb1 /media/linux/DATA2j'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 Marc Quinton . Évalué à 5.
merci et bravo pour le retour ; voici ce que j'ai sur mon NAS avec des warning un peu similaires.
[^] # Re: résolu
Posté par jeremyb14 . Évalué à 6.
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 Marc Quinton . Évalué à 3.
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 jeremyb14 . Évalué à 4.
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 mahikeulbody . Évalué à 3. 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 Marc Quinton . Évalué à 2.
merci pour le feedback.
pour compléter, il existe un paquet debian permettant de gérer des taches de maintenance de facon périodique : https://github.com/qiwichupa/btrfsmaintenance
[^] # Re: résolu
Posté par cg . Évalué à 5.
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 jeremyb14 . Évalué à 4.
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 Mikis . Évalué à 2.
La compression des données peut être utile, même dans le cadre d'une utilisation personnelle.
[^] # Re: résolu
Posté par cg . Évalué à 4. 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 jeremyb14 . Évalué à 2.
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 mahikeulbody . Évalué à 4. Dernière modification le 26 février 2024 à 09:32.
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 mahikeulbody . Évalué à 3.
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 BAud (site web personnel) . Évalué à 6. Dernière modification le 26 février 2024 à 18:33.
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 cg . Évalué à 2.
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/cachedansfree).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 :
Alors sur un serveur qui travaille…
[^] # Re: résolu
Posté par mahikeulbody . Évalué à 2.
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 cg . Évalué à 4.
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 Andre Rodier (site web personnel) . Évalué à 5.
BRTFS, c'est quoi ? Le système de fichier de Bart Simpson ?
Dans ce cas, c'est pas étonnant qu'il soit instable, non ?
[^] # Re: Bart filesystem ?
Posté par jeremyb14 . Évalué à 2.
Oui c'est vrai j'ai inversé : c'est BTRFS et non BRTFS
désolé.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.