Bonjour à tous sur la liste,
[à tort j'ai posté vers frsag-tech@frsag.org. Second envoi, il y aura peut-être un doublon.]
sur un serveur de fichiers Ubuntu en service depuis des années, normalement mis à jour, et où sont assemblées plusieurs grappes RAID1 logicielles, celles d'entre elles dont un des volumes physiques est un SSD, présentent une propriété surprenante:
- md assemble la grappe sans incident, elle est clean; - lvm utilise cette grappe comme volume physique et active le volume logique existant; - fsck.ext4 -f ne parvient à trouver aucune corruption du système de fichiers sur le LV;
On devrait donc être bons. Mais cependant;
- cmp --ignore-initial=0x8100000 (pour commencer après les métadonnées RAID) /dev/sda2 /dev/sdc1 identifie des dizaines de gigaoctets divergents entre le HDD et le SSD de la même grappe.
On est en RAID1, donc ça fait un peu accélérer le rythme cardiaque, est-ce une corruption massive? Comment ça pourrait reste sans conséquence dans le système de fichiers ?!? Inutile de descendre dans les valeurs SMART des disques physiques, elles n'apprennent ici rien d'utile.
cmp n'est pas super adapté pour attraper une vue d'ensemble de bloc devices en centaines de giga, et hexedit aide à peine mieux. Après une exploration très partielle, il semble que:
- quand un octet diverge entre les membres de la grappe RAID, c'est toujours parce que des zéros apparaissent sur l'autre disque;
- le disque sur lequel apparaissent les zéros semble toujours être le SSD.
L'hypothèse pour laquelle j'espère vos commentaires est celle formulée par Gemini: d'après le LLM, l'option discard/trim serait activée, et c'est elle qui est à l'origine des valeurs nulles sur le SSD. Le LLM suppose que ces divergences de données entre les deux membres de la grappe RAID1 apparaissent probablement sur tous les blocs où des fichiers ont été effacés. L'autre hypothèse est que le LLM hallucine.
Avant de me lancer dans l'écriture d'un script pour confirmer l'hypothèse des seuls zéros sur le seul SSD, et explorer la grappe raid systématiquement, existe-t-il un outil plus adapté que cmp, dd, hexedit pour "survoler" un disque et visualiser des patterns ? Et si l'hypothèse de Gemini est valide, quelle est la bonne pratique pour une grappe dont l'un des membres est un SSD ? Bien vérifier partout (fstab, systemd, ?) que rien sur le système n'émet de commande ATA Trim ? Dans cette configuration, en écriture la grappe RAID1 est déjà contrainte par les performances du HDD (il est marqué en writemostly), donc on peut peut-être se passer de trim sur le SSD ?
Dans l'état actuel incohérent de la grappe RAID1, même s'il n'y avait réellement aucune corruption des données utiles, en pratique on ne peut plus forcer de vérification manuelle utile avec mdadm, et ça, ce n'est pas vraiment une conséquence acceptable.
Merci pour vos avis.
-- Frédéric Dumas f.dumas@ellis.siteparc.fr
-- Frédéric Dumas f.dumas@ellis.siteparc.fr
Hello,
Tes LVs sont en thick provisioning ou en thin provisioning ? Car en thick, le discard n'a lieu que quand tu fais un lvremove ou lvresize, pas quand tu fais un fstrim. AFAIK, le fstrim est efficace quand ton LV est sur un thinpool et que le issue_discards est bien à 1 dans ton lvm.conf.
Le trim est conf sur ta machine ? Via une option de montage ou un timer systemd ?
Quand tu dis que mdadm ne peut pas faire de vérification utile, tu peux faire un echo check > /sys/block/mdX/md/sync_action et il te dira si des blocs mismatch si tu as activé les notifs du démon mdadm.
Ça ne répond pas à ton besoin ?
My 2cts, Nathan
Le ven. 31 oct. 2025, 09:06, Frederic Dumas f.dumas@ellis.siteparc.fr a écrit :
Bonjour à tous sur la liste,
[à tort j'ai posté vers frsag-tech@frsag.org. Second envoi, il y aura peut-être un doublon.]
sur un serveur de fichiers Ubuntu en service depuis des années, normalement mis à jour, et où sont assemblées plusieurs grappes RAID1 logicielles, celles d'entre elles dont un des volumes physiques est un SSD, présentent une propriété surprenante:
- md assemble la grappe sans incident, elle est clean;
- lvm utilise cette grappe comme volume physique et active le volume
logique existant;
- fsck.ext4 -f ne parvient à trouver aucune corruption du système de
fichiers sur le LV;
On devrait donc être bons. Mais cependant;
- cmp --ignore-initial=0x8100000 (pour commencer après les métadonnées
RAID) /dev/sda2 /dev/sdc1 identifie des dizaines de gigaoctets divergents entre le HDD et le SSD de la même grappe.
On est en RAID1, donc ça fait un peu accélérer le rythme cardiaque, est-ce une corruption massive? Comment ça pourrait reste sans conséquence dans le système de fichiers ?!? Inutile de descendre dans les valeurs SMART des disques physiques, elles n'apprennent ici rien d'utile.
cmp n'est pas super adapté pour attraper une vue d'ensemble de bloc devices en centaines de giga, et hexedit aide à peine mieux. Après une exploration très partielle, il semble que:
quand un octet diverge entre les membres de la grappe RAID, c'est toujours parce que des zéros apparaissent sur l'autre disque;
le disque sur lequel apparaissent les zéros semble toujours être le SSD.
L'hypothèse pour laquelle j'espère vos commentaires est celle formulée par Gemini: d'après le LLM, l'option discard/trim serait activée, et c'est elle qui est à l'origine des valeurs nulles sur le SSD. Le LLM suppose que ces divergences de données entre les deux membres de la grappe RAID1 apparaissent probablement sur tous les blocs où des fichiers ont été effacés. L'autre hypothèse est que le LLM hallucine.
Avant de me lancer dans l'écriture d'un script pour confirmer l'hypothèse des seuls zéros sur le seul SSD, et explorer la grappe raid systématiquement, existe-t-il un outil plus adapté que cmp, dd, hexedit pour "survoler" un disque et visualiser des patterns ? Et si l'hypothèse de Gemini est valide, quelle est la bonne pratique pour une grappe dont l'un des membres est un SSD ? Bien vérifier partout (fstab, systemd, ?) que rien sur le système n'émet de commande ATA Trim ? Dans cette configuration, en écriture la grappe RAID1 est déjà contrainte par les performances du HDD (il est marqué en writemostly), donc on peut peut-être se passer de trim sur le SSD ?
Dans l'état actuel incohérent de la grappe RAID1, même s'il n'y avait réellement aucune corruption des données utiles, en pratique on ne peut plus forcer de vérification manuelle utile avec mdadm, et ça, ce n'est pas vraiment une conséquence acceptable.
Merci pour vos avis.
-- Frédéric Dumas f.dumas@ellis.siteparc.fr
-- Frédéric Dumas f.dumas@ellis.siteparc.fr
Liste de diffusion du French Sysadmin Group https://www.frsag.org/
Le Fri, Oct 31, 2025 at 10:05:03AM +0200, Frederic Dumas [f.dumas@ellis.siteparc.fr] a écrit: (...)
On devrait donc être bons. Mais cependant;
- cmp --ignore-initial=0x8100000 (pour commencer après les métadonnées RAID) /dev/sda2 /dev/sdc1 identifie des dizaines de gigaoctets divergents entre le HDD et le SSD de la même grappe.
On est en RAID1, donc ça fait un peu accélérer le rythme cardiaque, est-ce une corruption massive? Comment ça pourrait reste sans conséquence dans le système de fichiers ?!? Inutile de descendre dans les valeurs SMART des disques physiques, elles n'apprennent ici rien d'utile.
Je ne connais pas assez bien discard/trim pour les SSD pour donner un avis la dessus.
Mais ce que tu decris pourrait tout aussi bien etre que les zones pour lesquelles ton SSD fait apparaitre un 0, et ton disque "autre chose", ce soit parcequ'il n'y a jamais rien eu « d'utile » d'écrit à cet emplacement.
Si les 2 disques de ton RAID1 sont ceux utilisés lors de la création, l'assemblage du device avec mdadm --create n'a sans doute pas initialisé les 2 disques avec un contenu identique. [1]
Si tu es dans ce cas là et que tu peux te permettre de le faire, force un rebuild via mdadm en sortant l'un des 2 (le SSD ?) et en le remettant.
[1] test vite-fait
/tmp$ dd if=/dev/zero of=file0 bs=1M count=10 /tmp$ dd if=/dev/random of=fileR bs=1M count=10 /tmp$ sudo losetup -f ./file0 /tmp$ sudo losetup -f ./fileR /tmp$ sudo mdadm -C --create /dev/md0 --level=1 --raid-devices=2 /dev/loop0 /dev/loop1 /tmp$ cat /proc/mdstat Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] md0 : active raid1 loop1[1] loop0[0] 9216 blocks super 1.2 [2/2] [UU]
Sans rien avoir écrit dedans :
/tmp$ hexdump -C file0 |grep 00001200 00001200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| /tmp$ hexdump -C fileR |grep 00001200 00001200 65 64 d2 31 05 0f 1e db 2b 58 c0 42 c0 f5 93 0d |ed.1....+X.B....|
( 0x1200, parceque c'est la où commence la partie "tout a zero" de file0 )
Intéressent, le fait qu’un disque soit (très) différent me semble être un problème d’architecture de stockage et le mieux serait de remplacer/reconstruire ce disque en HDD non?
-pph
On 31 Oct 2025, at 09:44, Dominique Rousseau d.rousseau@nnx.com wrote:
Le Fri, Oct 31, 2025 at 10:05:03AM +0200, Frederic Dumas [f.dumas@ellis.siteparc.fr] a écrit: (...)
On devrait donc être bons. Mais cependant;
- cmp --ignore-initial=0x8100000 (pour commencer après les métadonnées RAID)
/dev/sda2 /dev/sdc1 identifie des dizaines de gigaoctets divergents entre le HDD et le SSD de la même grappe.
On est en RAID1, donc ça fait un peu accélérer le rythme cardiaque, est-ce une corruption massive? Comment ça pourrait reste sans conséquence dans le système de fichiers ?!? Inutile de descendre dans les valeurs SMART des disques physiques, elles n'apprennent ici rien d'utile.
Je ne connais pas assez bien discard/trim pour les SSD pour donner un avis la dessus.
Mais ce que tu decris pourrait tout aussi bien etre que les zones pour lesquelles ton SSD fait apparaitre un 0, et ton disque "autre chose", ce soit parcequ'il n'y a jamais rien eu « d'utile » d'écrit à cet emplacement.
Si les 2 disques de ton RAID1 sont ceux utilisés lors de la création, l'assemblage du device avec mdadm --create n'a sans doute pas initialisé les 2 disques avec un contenu identique. [1]
Si tu es dans ce cas là et que tu peux te permettre de le faire, force un rebuild via mdadm en sortant l'un des 2 (le SSD ?) et en le remettant.
[1] test vite-fait
/tmp$ dd if=/dev/zero of=file0 bs=1M count=10 /tmp$ dd if=/dev/random of=fileR bs=1M count=10 /tmp$ sudo losetup -f ./file0 /tmp$ sudo losetup -f ./fileR /tmp$ sudo mdadm -C --create /dev/md0 --level=1 --raid-devices=2 /dev/loop0 /dev/loop1 /tmp$ cat /proc/mdstat Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] md0 : active raid1 loop1[1] loop0[0] 9216 blocks super 1.2 [2/2] [UU]
Sans rien avoir écrit dedans :
/tmp$ hexdump -C file0 |grep 00001200 00001200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| /tmp$ hexdump -C fileR |grep 00001200 00001200 65 64 d2 31 05 0f 1e db 2b 58 c0 42 c0 f5 93 0d |ed.1....+X.B....|
( 0x1200, parceque c'est la où commence la partie "tout a zero" de file0 )
-- Dominique Rousseau Neuronnexion, Prestataire Internet & Intranet 6 rue des Hautes cornes - 80000 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop _______________________________________________ Liste de diffusion du French Sysadmin Group https://www.frsag.org/
Hello, est ce que tes données SMART te disent que les 2 disques sont 100% sains ? Si oui je ne m'inquiéterais pas trop de corruption discrète qui ne serait pas vue par fsck. Un peu étrange ton setup, et tu t'embêtes avec des analyses bas niveau alors que si tu utilisais un système de fichier comme brtfs ou ZFS, avec des sommes de contrôle, tu n'aurais pas d'inquiétude. En plus avec un setup RAID1 asymétrique, HDD et SSD, tu ne bénéficie pas de tout l'avantage de performance de ton SSD. Si tu cherches à fiabiliser et accélérer avec juste 1 disque de plus je te conseilles du RAID1 btrfs entre 2 HDD, en utilisant ton ancien SSD comme cache avec bcache ou autre. Cdt
On Fri, Oct 31, 2025, 12:38 Pierre pbraun@nethence.com wrote:
Intéressent, le fait qu’un disque soit (très) différent me semble être un problème d’architecture de stockage et le mieux serait de remplacer/reconstruire ce disque en HDD non?
-pph
On 31 Oct 2025, at 09:44, Dominique Rousseau d.rousseau@nnx.com wrote:
Le Fri, Oct 31, 2025 at 10:05:03AM +0200, Frederic Dumas [
f.dumas@ellis.siteparc.fr] a écrit:
(...)
On devrait donc être bons. Mais cependant;
- cmp --ignore-initial=0x8100000 (pour commencer après les métadonnées
RAID)
/dev/sda2 /dev/sdc1 identifie des dizaines de gigaoctets divergents entre le HDD et le SSD
de la même grappe.
On est en RAID1, donc ça fait un peu accélérer le rythme cardiaque, est-ce une corruption massive? Comment ça pourrait reste sans conséquence dans le système de fichiers ?!? Inutile de descendre dans les valeurs SMART des disques physiques, elles n'apprennent ici rien d'utile.
Je ne connais pas assez bien discard/trim pour les SSD pour donner un avis la dessus.
Mais ce que tu decris pourrait tout aussi bien etre que les zones pour lesquelles ton SSD fait apparaitre un 0, et ton disque "autre chose", ce soit parcequ'il n'y a jamais rien eu « d'utile » d'écrit à cet emplacement.
Si les 2 disques de ton RAID1 sont ceux utilisés lors de la création, l'assemblage du device avec mdadm --create n'a sans doute pas initialisé les 2 disques avec un contenu identique. [1]
Si tu es dans ce cas là et que tu peux te permettre de le faire, force un rebuild via mdadm en sortant l'un des 2 (le SSD ?) et en le remettant.
[1] test vite-fait
/tmp$ dd if=/dev/zero of=file0 bs=1M count=10 /tmp$ dd if=/dev/random of=fileR bs=1M count=10 /tmp$ sudo losetup -f ./file0 /tmp$ sudo losetup -f ./fileR /tmp$ sudo mdadm -C --create /dev/md0 --level=1 --raid-devices=2
/dev/loop0 /dev/loop1
/tmp$ cat /proc/mdstat Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] md0 : active raid1 loop1[1] loop0[0] 9216 blocks super 1.2 [2/2] [UU]
Sans rien avoir écrit dedans :
/tmp$ hexdump -C file0 |grep 00001200 00001200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|................|
/tmp$ hexdump -C fileR |grep 00001200 00001200 65 64 d2 31 05 0f 1e db 2b 58 c0 42 c0 f5 93 0d
|ed.1....+X.B....|
( 0x1200, parceque c'est la où commence la partie "tout a zer
https://www.google.com/maps/search/la+o%C3%B9+commence+la+partie+%22tout+a+zer?entry=gmail&source=go" de file0 )
-- Dominique Rousseau Neuronnexion, Prestataire Internet & Intranet 6 rue des Hautes cornes - 80000 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop _______________________________________________ Liste de diffusion du French Sysadmin Group https://www.frsag.org/
Liste de diffusion du French Sysadmin Group https://www.frsag.org/
Bonjour,
Pour vérifier si le SSD contient bien les données, tu pourrais le dumper sur un autre disque avec DD par exemple, et essayer de monter le raid en degradé sur une autre machine.
Tu verrais si tu as de la donnée, si elle parait cohérente,
On pourrait même vérifier la cohérence complète en faisant un rsync depuis ta source sur ton disque dumpé. Tu verrais si tout est à l'identique ou pas avec des outils qui font déja le travail ;)
Ton travail d'écriture de script en serait grandement réduit ;)
Ca permettrait de vérifier l'hypothèse de la non initialisation du disque à 0 lors de la création du raid de Dominique, qui me plait bien.
Cordialement,
Thomas
Le 31/10/2025 à 09:43, Dominique Rousseau a écrit :
Le Fri, Oct 31, 2025 at 10:05:03AM +0200, Frederic Dumas [f.dumas@ellis.siteparc.fr] a écrit: (...)
On devrait donc être bons. Mais cependant;
- cmp --ignore-initial=0x8100000 (pour commencer après les métadonnées RAID) /dev/sda2 /dev/sdc1 identifie des dizaines de gigaoctets divergents entre le HDD et le SSD de la même grappe.
On est en RAID1, donc ça fait un peu accélérer le rythme cardiaque, est-ce une corruption massive? Comment ça pourrait reste sans conséquence dans le système de fichiers ?!? Inutile de descendre dans les valeurs SMART des disques physiques, elles n'apprennent ici rien d'utile.
Je ne connais pas assez bien discard/trim pour les SSD pour donner un avis la dessus.
Mais ce que tu decris pourrait tout aussi bien etre que les zones pour lesquelles ton SSD fait apparaitre un 0, et ton disque "autre chose", ce soit parcequ'il n'y a jamais rien eu « d'utile » d'écrit à cet emplacement.
Si les 2 disques de ton RAID1 sont ceux utilisés lors de la création, l'assemblage du device avec mdadm --create n'a sans doute pas initialisé les 2 disques avec un contenu identique. [1]
Si tu es dans ce cas là et que tu peux te permettre de le faire, force un rebuild via mdadm en sortant l'un des 2 (le SSD ?) et en le remettant.
[1] test vite-fait
/tmp$ dd if=/dev/zero of=file0 bs=1M count=10 /tmp$ dd if=/dev/random of=fileR bs=1M count=10 /tmp$ sudo losetup -f ./file0 /tmp$ sudo losetup -f ./fileR /tmp$ sudo mdadm -C --create /dev/md0 --level=1 --raid-devices=2 /dev/loop0 /dev/loop1 /tmp$ cat /proc/mdstat Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] md0 : active raid1 loop1[1] loop0[0] 9216 blocks super 1.2 [2/2] [UU]
Sans rien avoir écrit dedans :
/tmp$ hexdump -C file0 |grep 00001200 00001200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| /tmp$ hexdump -C fileR |grep 00001200 00001200 65 64 d2 31 05 0f 1e db 2b 58 c0 42 c0 f5 93 0d |ed.1....+X.B....|
( 0x1200, parceque c'est la où commence la partie "tout a zero" de file0 )
Bonsoir,
On 31 Oct 2025, at 9:05 , Frederic Dumas f.dumas@ellis.siteparc.fr wrote:
où sont assemblées plusieurs grappes RAID1 logicielles, celles d'entre elles dont un des volumes physiques est un SSD
C’est-à-dire que vous avez des miroirs RAID-1 entre un HDD et un SSD ? Étrange idée, quel intérêt ? Pas forcément les même tailles de blocs, plus les mécanismes spécifiques aux SDD tels que TRIM… Le seul scénario qui me vient à l’esprit our mélanger des HDD et des SSD dans un même pool de stockage serait du cache ZFS ou du tiering chez certains fournisseurs de baies de stockage.
Bon weekend.
Le Fri, Oct 31, 2025 at 08:43:40PM +0100, Fx (frsag) [efishp+frsag@gmail.com] a écrit:
Bonsoir,
On 31 Oct 2025, at 9:05 , Frederic Dumas f.dumas@ellis.siteparc.fr wrote:
où sont assemblées plusieurs grappes RAID1 logicielles, celles d'entre elles dont un des volumes physiques est un SSD
C???est-à-dire que vous avez des miroirs RAID-1 entre un HDD et un SSD ? Étrange idée, quel intérêt ? Pas forcément les même tailles de blocs, plus les mécanismes spécifiques aux SDD tels que TRIM??? Le seul scénario qui me vient à l???esprit our mélanger des HDD et des SSD dans un même pool de stockage serait du cache ZFS ou du tiering chez certains fournisseurs de baies de stockage.
Il y a plein de plus ou moins bonnes raisons, qui n'ont rien a voir avec le probleme de Frederic :)
Par exemple, une partie du HDD seulement utilisee pour le RAID, en accord avec la capacite du SSD, et un autre usage juge moins critique pour le reste ( ce ne sont par exemple pas les memes numeros de partition dans le mail initial ).
Pour s'assurer, a l'extreme, de cycles d'usure differents, pour ne pas "casser" les deux en meme temps.
Pour profiter de la capacite du noyau a differencier les usages ( option --write-mostly de mdadm + heuristiques internes ).
Et surement d'autres :)
-
Dominique Rousseau -
Fabien Schwebel -
Frederic Dumas -
Fx (frsag) -
Nathan MALO -
Pierre -
Thomas Dubois