Volume BTRFS en panne (Raid SHR1)

Tags: #<Tag:0x00007f151279e4a0> #<Tag:0x00007f151279e3b0>

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:

--- 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

--- 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

mount: mount point /Volume2 does not exist

Bonjour @PascalCranshoff

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é ?

Bonjour @doo
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

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:

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 :frowning:

Je suis aussi perdu que toi :confused:

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 »

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

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/ ?

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).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/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:~$ 

je suis avec dsm…:flushed:

j’ai cela:

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

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 :slight_smile:

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 @doo 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 :wink:

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

Merci pour les explications.

Oui, tu as raison.
J’étais un peu distrait et j’ai fait une petite confusion entre LVM et RAID :face_with_hand_over_mouth:

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.

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/

Le SHR de Synology correspond à une couche raid (mdadm) et une couche de LVM.

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.

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 ?