Path: ...!feeds.phibee-telecom.net!3.eu.feeder.erje.net!feeder.erje.net!fdn.fr!news.ortolo.eu!.POSTED.localhost!not-for-mail
From: Tanguy Ortolo <tanguy@ortolo.eu>
Newsgroups: fr.comp.os.linux.configuration
Subject: Re: Passage =?UTF-8?Q?=C3=A0?= Btrfs
Date: Mon, 10 Mar 2025 08:19:56 -0000 (UTC)
Sender: tanguy@localhost
Message-ID: <vqm7bc$1ecr3$1@herbert.ortolo.eu>
References: <vqenjd$19kj8$1@herbert.ortolo.eu> <vqf7gr$4st$16@rasp.pasdenom.info>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 10 Mar 2025 08:19:56 -0000 (UTC)
Injection-Info: herbert.ortolo.eu; posting-account="tanguy"; posting-host="localhost:::1";
	logging-data="1520483"; mail-complaints-to="usenet@ortolo.eu"
User-Agent: tin/2.6.2-20221225 ("Pittyvaich") (Linux/6.12.9+bpo-amd64 (x86_64))
Cancel-Lock: sha1:MxsvmPM6GPolA3d8UXYWH3f7Oj4=
Bytes: 3249
Lines: 42

Jo Engo, 2025-03-07 17:39+0100:
> Le Fri, 7 Mar 2025 12:08:13 -0000 (UTC), Tanguy Ortolo a écrit :
>> Pas moyen de savoir laquelle a été dégradée et laquelle est correcte.
> 
> C'est faux, ou très improbable (qu'il n'y a pas moyen de savoir qui est le 
> faux et qui est le vrai). Tes données sont en principe signée, la bonne 
> est celle qui a la bonne signature (1000 excuses au puriste si le terme 
> signature est inadéquat) en gros si ton mot est à 64 bits, quelques bits 
> supplémentaires sont utilisé pour la signature. 

Je crois qu'on précision s'impose en effet. Pour rappel, ce paragraphe
concernait le RAID1 mis en place à l'aide de lvmraid(7).

Les périphériques de stockage incluent normalement des codes de
correction d'erreur, mais en interne, non accessibles à l'utilisateur ou
au système d'exploitation. On écrit des données, et quand on les lit, le
périphérique utilise cela pour détecter et corriger silencieusement une
éventuelle corruption. Sauf que parfois, ça ne suffit par et il renvoie
tout de même des données altérées. Cette première couche de correction
d'erreurs n'est pas inintéressante mais elle n'a rien à voir avec la
redondance en RAID logiciel et est inutilisable pour détecter les cas de
corruption qui passeraient au travers.

Quand à lvmraid, je maintiens que, sans option supplémentaire, c'est à
dire après avoir fait un simple `lvcreate --type raid1`, il n'inclut
aucun moyen de détecter, en cas de conflit entre les données relues
depuis plusieurs périphériques, lequel est corrompu. Je n'invente rien,
vous pouvez vérifier dans la page de manuel lvmraid(7), à la
sous-section /Scrubbing Limitations/.

C'est pour cette raison qu'il existe une option pour ajouter une couche
d'intégrité, cf. section /DATA INTEGRITY/ dans cette même page de
manuel. Cela permet bien à lvmraid de déterminer, en cas de conflit,
d'où vient la corruption, de prendre les bonnes données, et de les
ré-écrire au passage sur le périphérique où elles étaient altérées. En
revanche, dans ce genre de cas, les outils LVM permettent seulement de
connaître le nombre d'erreurs, et ne fournissent aucun moyen de savoir
quel périphérique les a produites.

-- 
.. o .
.. . o       Tanguy
o o o