Reconstruction MD RAID1 compatible SSD / NVME sous Linux

Oct 06 2020

J'utilise des baies SSD et NVME RAID1 pour stocker principalement des disques de machine virtuelle. Plus de 75% des données sont des zéros (images préallouées, espace libre).

Si un disque tombe en panne et est remplacé, la reconstruction copie et écrit toutes les données sur le disque de remplacement, ce qui provoque une limitation thermique dans NVME, et je suppose une usure plus importante du SSD / NVME. Existe-t-il un moyen de configurer la reconstruction pour comparer d'abord les données des deux disques et écrire sur le nouveau disque uniquement si nécessaire?

Ou est-ce que les puces SSD / NVME sont censées vérifier si les données ne sont que des zéros et si les blocs cibles ne sont pas encore écrits (donnant des zéros en lecture), cela rejetterait simplement les données sans perdre de cycles d'écriture? Ou s'il y a des données cibles, devrait-il simplement couper le bloc pour produire des zéros?

J'ai trouvé un vieux fil à https://www.spinics.net/lists/raid/msg57529.html mais il n'a pas fourni de réponse.

J'ai essayé une solution de contournement mais je pense que c'est moche et que le RAID doit être hors ligne.

mdadm --fail /dev/md0 /dev/sde
mdadm -r /dev/md0 /dev/sde

(remplacer / dev / sde)

mdadm -S /dev/md0
ddpt if=/dev/sdd of=/dev/sde verbose=1 oflag=sparing
mdadm -C -v /dev/md0 --assume-clean -l 1 -n 2 /dev/sdd /dev/sde

Des idées pour la reconstruction RAID1 de comparaison-écriture? Merci.

Réponses

2 Nils Oct 11 2020 at 04:41

La réponse courte est non.

Le pilote md est optimisé pour les performances. Et il a une carte simplement sale pour garder les membres du raid 1 synchronisés.

Donc, si un membre échoue, toute la carte est sale. Puisque md est simplement basé sur des blocs, il ne prend pas en compte le contenu des blocs, il copie simplement les blocs et efface les bits modifiés pour ces blocs.

Principe de KISS_ garder les choses simples et stupides. Tout le reste serait à un niveau supérieur.

Si vous le souhaitez, vous pouvez utiliser drbd avec deux membres locaux au lieu de md raid1. DRBD fournit les moyens de vérifier avant la synchronisation.

2 JohnLeeMcMahon Oct 16 2020 at 10:00

Donc, la seule façon de faire une reconstruction de comparaison-écriture dans MDRAID1 (à part la synchronisation hors ligne par exemple ddpt) semble être la réparation (le tableau doit être arrêté et reconfiguré lors du remplacement du disque, le bon disque doit passer en premier dans le nouveau tableau pour devenir l'ID 0 et la source de données)

mdadm -C -v /dev/md0 -l 1 -n 2 /dev/sdd /dev/sde
mdadm /dev/md0 -f /dev/sdd -r /dev/sdd
mdadm -S /dev/md0
mdadm -C -v /dev/md0 -l 1 -n 2 --assume-clean /dev/sde /dev/sdd
echo repair > /sys/block/md0/md/sync_action

Cela semble également fonctionner pour plusieurs miroirs:

mdadm -C -v /dev/md0 -l 1 -n 3 /dev/sdd /dev/sde /dev/sdf
mdadm /dev/md0 -f /dev/sde -f /dev/sdf -r /dev/sde -r /dev/sdf
mdadm -S /dev/md0
mdadm -C -v /dev/md0 -l 1 -n 3 --assume-clean /dev/sdd /dev/sde /dev/sdf
echo repair > /sys/block/md0/md/sync_action

J'ai également expérimenté des idées de remodelage du tableau sans s'arrêter (RAID0 -> RAID1_or_RAID10 -> RAID0), mais je n'ai pas vu de comparaison-écriture dans RAID10 (apparemment utilisé pour RAID10 par le thread linux-raid d'origine) et les choses ne fonctionnent pas comme Je m'attendais à des conversions RAID0 -> RAID1.