Path: ...!weretis.net!feeder6.news.weretis.net!feeder8.news.weretis.net!news.imp.ch!news.alphanet.ch!alphanet.ch!.POSTED.localhost!not-for-mail
From: Marc SCHAEFER <schaefer@alphanet.ch>
Newsgroups: fr.comp.os.linux.configuration
Subject: Re: Monter un raid pour copier un disque vers un nouveau sur un
 raspberry pi2 =?ISO-8859-1?Q?chroot=E9=2E?=
Date: Fri, 7 Jan 2022 09:31:44 -0000 (UTC)
Organization: Posted through ALPHANET
Message-ID: <sr91a0$u4e$3@shakotay.alphanet.ch>
References: <sr7elu$e2p$1@rasp.pasdenom.info> <sr7fel$10i$1@shakotay.alphanet.ch> <sr7l61$4j7$1@gioia.aioe.org> <sr8ujb$kh4$3@shakotay.alphanet.ch> <sr902d$1irf$1@gioia.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 7 Jan 2022 09:31:44 -0000 (UTC)
Injection-Info: shakotay.alphanet.ch; posting-host="localhost:127.0.0.1";
	logging-data="30862"; mail-complaints-to="usenet@alphanet.ch"
User-Agent: tin/2.4.3-20181224 ("Glen Mhor") (UNIX) (Linux/4.19.0-18-amd64 (x86_64))
Cancel-Lock: sha256:TPBicta5X2bCbOG/8WmXnJnYXLbLuxGlHdfmXT8Zu6k=
Bytes: 3624
Lines: 57

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.