Re: Monter un raid pour copier un disque vers un nouveau sur un raspberry pi2 chrooté.

Matthieu <matthieu@x.localhost> wrote:

Oui mais le problème c'est lorsque la donnée change sans provoquer
d'erreur de la part du disque.

Avec des relectures régulières, cela se produit si:

1) le disque est mal configuré dans la gestion des erreurs
   (fin 1990 on livrait des disques optimisé "vidéo", avec plein
    de paramètres de correction d'erreurs supprimés)

2) le type d'erreur dépasse immédiatement la puissance détectrice
   du code ECC du disque

3) c'est une erreur dans le transport des données

4) c'est une erreur dans le stockage en RAM des données

car je manque de statistiques, mais j'ai eu le cas au moins deux fois
sur mes RAIDs btrfs (et probablement avant aussi, mais sans m'en rendre
compte car sans btrfs ou zfs ce type de situation est difficile à
détecter).

Ne pas oublier 3) et 4).

2) est peu probable en cas de relectures régulières et si le disque
fait l'équivalent de SCSI "REALLOCATE ON READ ERROR".

1) ne m'étonnerait pas du tout que certaines "couleurs" de disques
   WD par exemple aient des préconfiguration de gestion d'erreur
   différentes

3) https://www.kernel.org/doc/Documentation/block/data-integrity.txt

   "The solution is to ensure that the disk is actually storing what the
application meant it to.  Recent additions to both the SCSI family
protocols (SBC Data Integrity Field, SCC protection proposal) as well
as SATA/T13 (External Path Protection) try to remedy this by adding
support for appending integrity metadata to an I/O.  The integrity
metadata (or protection information in SCSI terminology) includes a
checksum for each sector as well as an incrementing counter that
ensures the individual sectors are written in the right order.  And
for some protection schemes also that the I/O is written to the right
place on disk."

   "data path checksumming"

4) peu probable avec de la RAM ECC et un contrôleur compatible

NB: j'ai peu d'expérience en SATA, je travaillais dans le domaine du
stockage fin 1990 et début 2000, surtout SCSI.

Imaginons donc un octet qui change sur un des deux disques du raid. Une
comparaison permet de détecter qu'il y a un problème (c'est ce que fait
d'ailleurs un scrub mdadm), mais que faire ensuite? On ne sait pas
laquelle des deux versions est bonne. btrfs (et zfs aussi) le sait,
lui, et c'est toute sa force.

Tout à fait.