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