# Volume BTRFS en panne (Raid SHR1) **URL:** \ **Category:** Pause Café\ **Tags:** synology, dsm\ **Created:** [Avril 10, 2020, 11:37 UTC](https://www.debian-fr.org/t/volume-btrfs-en-panne-raid-shr1/81748 "2020-04-10T11:37:14Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![PascalCranshoff](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalcranshoff/32/9090_2.png) [@PascalCranshoff](https://www.debian-fr.org/u/PascalCranshoff)\ **Post date:** [Avril 10, 2020, 11:37 UTC](https://www.debian-fr.org/t/volume-btrfs-en-panne-raid-shr1/81748/1 "2020-04-10T11:37:14Z")
Bonjour. Je rame depuis plusieurs jours pour retrouver mes données suite à un plantage de mon système. tout mes dossiers partagés du mon volume2 ont disparus alors que la synchronisation de mon Raid est ok et que mon volume est apparament ok. **lvdisplay:** ```nohighlight --- Logical volume --- LV Path /dev/vg1000/lv LV Name lv VG Name vg1000 LV UUID Iv9ZJ0-oN3I-K6jV-76Px-gIbp-Fqc4-8ohokw LV Write Access read/write LV Creation host, time , LV Status available # open 0 LV Size 7.26 TiB Current LE 1904185 Segments 2 Allocation inherit Read ahead sectors auto - currently set to 512 Block device 253:0 ``` **vgdisplay** ```nohighlight --- Volume group --- VG Name vg1000 System ID Format lvm2 Metadata Areas 2 Metadata Sequence No 2 VG Access read/write VG Status resizable MAX LV 0 Cur LV 1 Open LV 0 Max PV 0 Cur PV 2 Act PV 2 VG Size 7.26 TiB PE Size 4.00 MiB Total PE 1904185 Alloc PE / Size 1904185 / 7.26 TiB Free PE / Size 0 / 0 VG UUID jW6np5-2yEZ-OeOI-ioZh-9pjf-g6KR-K5wXs9 ``` **mount /dev/vg1000/lv /Volume2** ```nohighlight mount: mount point /Volume2 does not exist ``` ---
**Author:** ![anon61356901](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/cab0a1/32.png) [@anon61356901](https://www.debian-fr.org/u/anon61356901)\ **Post date:** [Avril 10, 2020, 12:03 UTC](https://www.debian-fr.org/t/volume-btrfs-en-panne-raid-shr1/81748/2 "2020-04-10T12:03:41Z")
Bonjour @PascalCranshoff > [@PascalCranshoff](#): > > **mount /dev/vg1000/lv /Volume2** > mount: mount point /Volume2 does not exist Le répertoire `/Volume2` n’existe pas. La commande `mount` ne peut monter ton LV nommé lv sur un répertoire inexistant. Vu rapidement, je dirais que tout va bien, sauf pour le dossier sur lequel tu veux monter ce LV « lv ». À toi de prendre ton temps pour savoir à quel endroit tu veux effectuer ce montage. Quitte à créer un nouveau répertoire pour le faire. Juste une remarque : `/Volume2` est à la racine du système de fichiers ! Est-ce vraiment l’endroit approprié ? ---
**Author:** ![PascalCranshoff](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalcranshoff/32/9090_2.png) [@PascalCranshoff](https://www.debian-fr.org/u/PascalCranshoff)\ **Post date:** [Avril 10, 2020, 12:17 UTC](https://www.debian-fr.org/t/volume-btrfs-en-panne-raid-shr1/81748/3 "2020-04-10T12:17:39Z")
Bonjour @anon61356901 non, tu as surement raison, je dois me planter ici sur l’emplacement de mon répertoire. du coup j’ai aussi essayer un simple montage en lecture seul mais là il me renvoie sur un problème de “`bad superblock`” ```nohighlight mount /dev/vg1000/lv /mnt -o ro mount: wrong fs type, bad option, bad superblock on /dev/vg1000/lv, missing codepage or helper program, or other error In some cases useful info is found in syslog - try dmesg | tail or so. ``` j’ai donc fait un dmesg et là voici ce qu’il me répond: ```nohighlight dmesg | tail [178859.705957] parent transid verify failed on 394340270080 wanted 940895 found 940897 [178859.705958] parent transid verify failed on 394340270080 wanted 940895 found 940897 [178859.705959] parent transid verify failed on 394340270080 wanted 940895 found 940897 [178859.705960] parent transid verify failed on 394340270080 wanted 940895 found 940897 [178859.705961] parent transid verify failed on 394340270080 wanted 940895 found 940897 [178859.705964] BTRFS error (device dm-0): BTRFS: dm-0 failed to repair parent transid verify failure on 394340270080, mirror = 1 [178859.714068] BTRFS error (device dm-0): BTRFS: dm-0 failed to repair parent transid verify failure on 394340270080, mirror = 2 [178859.723728] BTRFS: open_ctree failed ``` là je suis perdu face à la réponse ☹ ---
**Author:** ![anon61356901](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/cab0a1/32.png) [@anon61356901](https://www.debian-fr.org/u/anon61356901)\ **Post date:** [Avril 10, 2020, 12:21 UTC](https://www.debian-fr.org/t/volume-btrfs-en-panne-raid-shr1/81748/4 "2020-04-10T12:21:47Z")
Je suis aussi perdu que toi 😕 Si possible, il est urgent d’attendre une aide experte ; sans rien faire davantage. Cela n’empêche pas de se renseigner sur « failed to repair parent transid verify failure » Et « parent transid verify failed » ---
**Author:** ![PascalCranshoff](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalcranshoff/32/9090_2.png) [@PascalCranshoff](https://www.debian-fr.org/u/PascalCranshoff)\ **Post date:** [Avril 10, 2020, 12:34 UTC](https://www.debian-fr.org/t/volume-btrfs-en-panne-raid-shr1/81748/5 "2020-04-10T12:34:03Z")
oui, je compte bien rester patient et ne pas faire n’importe quoi. c’est dure car une commande amène une nouvelle recherche qui amène une nouvelle commande qui à nouveau amène une nouvelle recherche… J’ai l’impression de tourner en rond ou alors d’être balader d’une solution à une autre qui n’aboutissent pas, ce qui me donne à chaque fois l’impression d’avoir vraiment tout perdu ---
**Author:** ![anon61356901](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/cab0a1/32.png) [@anon61356901](https://www.debian-fr.org/u/anon61356901)\ **Post date:** [Avril 10, 2020, 12:41 UTC](https://www.debian-fr.org/t/volume-btrfs-en-panne-raid-shr1/81748/6 "2020-04-10T12:41:47Z")
Je suis avec buster. J’ai un RAID6 dont je monte avec le `/etc/fstab` les LV depuis `/dev/mapper/` Tu as quoi dans ton `/dev/mapper/` ? ```nohighlight rem@n40l:~$ cat /etc/fstab # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # /dev/mapper/vg0-racine / ext4 errors=remount-ro 0 1 /dev/mapper/vg0-boot /boot ext3 defaults 0 2 /dev/mapper/vg0-home /home ext4 defaults 0 2 /dev/mapper/vg0-opt /opt ext4 defaults 0 2 /dev/mapper/vg0-plex /plex ext4 defaults 0 2 /dev/mapper/vg0-root /root ext4 defaults 0 2 /dev/mapper/vg0-usr /usr ext4 defaults 0 2 /dev/mapper/vg0-src /usr/src ext4 defaults 0 2 /dev/mapper/vg0-var /var ext4 defaults 0 2 /dev/mapper/vg0-swap none swap sw 0 0 rem@n40l:~$ ``` ---
**Author:** ![PascalCranshoff](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalcranshoff/32/9090_2.png) [@PascalCranshoff](https://www.debian-fr.org/u/PascalCranshoff)\ **Post date:** [Avril 10, 2020, 12:49 UTC](https://www.debian-fr.org/t/volume-btrfs-en-panne-raid-shr1/81748/7 "2020-04-10T12:49:13Z")
je suis avec dsm…😳 > [@anon61356901](#): > > ```plaintext > cat /etc/fstab > > ``` j’ai cela: ```plaintext none /proc proc defaults 0 0 /dev/root / ext4 defaults 1 1 /dev/vg1000/lv /volume2 btrfs nospace_cache,synoacl,relatime,relatime_period=30 0 0 /dev/md2 /volume1 ext4 usrjquota=aquota.user,grpjquota=aquota.group,jqfmt=vfsv0,synoacl,relatime 0 0 ``` ---
**Author:** ![anon61356901](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/cab0a1/32.png) [@anon61356901](https://www.debian-fr.org/u/anon61356901)\ **Post date:** [Avril 10, 2020, 12:53 UTC](https://www.debian-fr.org/t/volume-btrfs-en-panne-raid-shr1/81748/8 "2020-04-10T12:53:54Z")
> [@PascalCranshoff](#): > > je suis avec dsm…😳 Pour mon point de vue, tu n’as pas à t’en faire car je ne connais pas. Tu pourrais te documenter sur la commande `checkarray` Bon, et bien il faut attendre alors 🙂 ---
**Author:** ![PascalCranshoff](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalcranshoff/32/9090_2.png) [@PascalCranshoff](https://www.debian-fr.org/u/PascalCranshoff)\ **Post date:** [Avril 10, 2020, 1:06 UTC](https://www.debian-fr.org/t/volume-btrfs-en-panne-raid-shr1/81748/9 "2020-04-10T13:06:12Z")
Checkarray, il me semble que c’est pour vérifier mon Raid or ce dernier est apparament ok puisqu’il a refait une synchro juste au redémarrage. et en fait c’est une commande non implantée dans mon système. Mon Raid est un SHR1, c’est un raid hybride qui mix du Raid5 avec du Raid1 et qui permet d’étendre le volume à la volée et y ajoutant un disque, tout en réduisant la quantité nécessaire à la réplication en miroir… Mon système de fichier est en btrfs, qui lui permet des snapshot sans devoir réécrire complétement tout les blocks de donnée et aussi une vérification en temps réel des duplications et points de restaurations et c’est bien lui je pense qui m’a joué un mauvais tour. Ou alors lors de la coupure de courant, il y a eu deux disques sur mes 4 qui n’ont pas eux le temps de finir leur inscription et donc aurait provoqué une perte seche de données. Mon système peut avoir une panne d’1 disque sans bronché, mais pas 2. Je n’arrive plus à répondre à la fin du poste. je place donc ma réponse @Clochette ici: Je faisais justement un simple consultation en winscp - ssh root et une recherche d’un dossier dans tout mon / lorsque ma cession ssh a figé… Plus aucun moyen d’atteindre DSM, que ce soit en SSH, FTP, HTTP et même le synology finder. J’ai vérifier sur le support syno ce qu’il y avait lieux de faire et c’était soit garder le boutton power enfoncé (ce qui n’a rien donné chez moi), soit de couper le courant (ce que j’ai horreur de faire mais ici pas d’autre choix). Du coup au redémarrage mon Raid s’est remis en synchronisation, tout les disques sont OK, mais le Volume reste en panne. Les logs de dsm ne me disaient rien d’autre que il y avait eu un redémarrage après une mauvaise interruption et que le volume et planté. Je n’ai pas vérifier les logs cli du btrfs mais je me suis de suite concentrer sur la solution de restauration des données et supposé que mon scan de dossier dans tout le / avait du interférer avec un fichiers de suivi snapshot btrfs et que l’interruption de courant n’avait pas donné le temps à 2 disques sur les 4 pour correctement ranger son fichier système. Ce qui est bizarre c’est qu’a aucun moment mon volume n’est passé en mode dégradé, mais simplement directement une synchro tout en laissant mon volume non montable pour DSM. Cela montre les risques à mélanger DSM FS + BTFRS + MDADM +LVM, il arrive un moment ou ils ne sont plus accordés. De plus selon mes recherches Synology utiliseraient leur propre repositery BTRFS dans leur kernel et cela afin de se réserver certains outils de gestions qui ne sont pas présents de leur systèmes et qu’ils uploadent lors d’un acces distant . Je n’ai reçu aucune aide valable sur le forum Synology officiel, mais par contre beaucoup d’aide du côté du forum XPENOLOGY ! J’ai pu remonter mon volume en lecture seule et je suis en train de recopier son contenu dans un autre NAS. Je vais donner en réponse @anon61356901 les quelques commandes qui m’ont sauvées cela pourrais-toujours sauver quelqu’un d’autre qui tomberai dans la pause café en faisant une recherche sur le web 😉 En tout cas, très sympa le forum Debian…les pistes déjà communiquées sont correctes et vos réponses n’ont pas tarder. Merci @Clochette ---
**Author:** ![anon61356901](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/a/cab0a1/32.png) [@anon61356901](https://www.debian-fr.org/u/anon61356901)\ **Post date:** [Avril 10, 2020, 11:32 UTC](https://www.debian-fr.org/t/volume-btrfs-en-panne-raid-shr1/81748/10 "2020-04-10T23:32:14Z")
Merci pour les explications. > [@PascalCranshoff](#): > > Checkarray, il me semble que c’est pour vérifier mon Raid Oui, tu as raison. J’étais un peu distrait et j’ai fait une petite confusion entre LVM et RAID 🤭 > [@PascalCranshoff](#): > > Mon système de fichier est en btrfs C’est le volume logique `/dev/vg1000/lv` qui doit effectivement être monté sur `/volume2` d’après ton `/etc/fstab`. `/Volume2` n’existe pas mais `/volume2` doit exister lui. ```plaintext ls -al /volume2 ``` Ce système de fichiers btrfs doit pouvoir être testé et vérifié. J’ai trouvé, surtout à titre d’information et pour étude : > Ce ne doit pas être pris et exécuté à la lettre sans bien comprendre auparavant ce que cela réalise. Tu pourrais demander dans un forum Synology si ce code est utilisable. Il y a certainement du bon, mais peut-être aussi une adaptation à faire. Je n’ai jamais eu affaire avec un volume logique en btrfs ; d’autant moins en SHR. > [https://www.cambier.org/2014/12/23/migration-de-shr-1-vers-shr-2/](https://www.cambier.org/2014/12/23/migration-de-shr-1-vers-shr-2/) > > Le [SHR](https://www.synology.com/fr-fr/knowledgebase/DSM/tutorial/Storage/What_is_Synology_Hybrid_RAID_SHR?q_id=492) de Synology correspond à une couche [raid](https://fr.wikipedia.org/wiki/RAID_%28informatique%29) (mdadm) et une couche de [LVM](https://fr.wikipedia.org/wiki/Gestion_par_volumes_logiques). > > Il existe 2 type de SHR : > > SHR-1 : raid avec 1 disque de parité > SHR-2 : raid avec 2 disques de parité Concernant dsm, c’est vrai que ta demande dans le support Debian n’est peut-être pas à sa place. Je te souhaite de trouver un interlocuteur compétent. ---
**Author:** ![Clochette](https://www.debian-fr.org/user_avatar/www.debian-fr.org/clochette/32/8757_2.png) [@Clochette](https://www.debian-fr.org/u/Clochette)\ **Post date:** [Avril 11, 2020, 8:32 UTC](https://www.debian-fr.org/t/volume-btrfs-en-panne-raid-shr1/81748/11 "2020-04-11T08:32:29Z")
> [@anon61356901](#): > > Concernant dsm, c’est vrai que ta demande dans le support Debian n’est peut-être pas à sa place. > Je te souhaite de trouver un interlocuteur compétent. Fil de discussion déplacé dans pause café, mais effectivement le mieux serait de voir sur un forum Synology, et attention il est fortement recommandé de ne faire que de la consultation en CLI sur un système DSM. Un volume qui disparait, ça n’arrive pas tous seul qu’y a t’il dans les logs à ce propos ?