Avec zfs, si vous en avez copies=2et que vous perdez ensuite un lecteur contenant certaines de ces copies, comment dire au système qu'il doit faire une nouvelle copie des blocs de données pour les fichiers concernés? Ou zfs commence-t-il simplement à ajouter des blocs de données pour les copies supplémentaires dès qu'il découvre les blocs de données défectueux?
Est-ce que le gommage fera cela?
(v0.6.0.56-rc8, version 28 du pool ZFS, système de fichiers ZFS version 5, Ubuntu 11.10)
"copies = 2" (ou 3) est plus conçu pour être utilisé avec des pools sans redondance (disque unique ou bandes). L'objectif est de pouvoir récupérer une corruption de disque mineure, pas une panne complète de l'appareil. Dans ce dernier cas, la piscine n'est pas montable donc aucune restauration de blocs idem ne peut se produire.
Si vous avez une redondance (mise en miroir / raidz / raidz2 / raidz3), les blocs idem ne sont pas différents des autres et le nettoyage / resilvering les recréera.
For a device to be replaced, the pool must be in the ONLINE state. The device must be part of a redundant configuration, or it must be healthy (in the ONLINE state).Je suppose que les copies = 2 ou 3 ne sont pas considérées comme une configuration redondante.copies=1et que vous l'avez augmentéecopies=2, vous voudrez probablement resilver / rescrub par la suite - ce qui créera ces instances. Mais @jilliagre a raison: les blocs idem ne constituent pas une configuration redondante. Il n'y a AUCUNE garantie que les blocs sont définis sur un autre appareil, même si vous avez plusieurs appareils dans un pool.J'ai trouvé cette question vraiment intrigante et après avoir passé une heure à parcourir la documentation, j'ai plongé dans le code. Voici ce que j'ai trouvé.
Tout d'abord, une terminologie. Les blocs idem (qui sont ce que sont ces copies, par opposition aux miroirs) sont automatiquement créés sur une écriture mais peuvent ou non être dans le même périphérique virtuel (vdev) que la copie d'origine. D'un autre côté, les blocs en miroir sont toujours réfléchis sur un autre périphérique virtuel.
Cependant, le code fait référence aux deux types de blocs en tant qu'enfants. Vous verrez ici que les blocs idem ne sont que des enfants
io_vd == NULL(c'est dans la fonction d'écriture). Pour un bloc en miroir,io_vdserait défini sur le périphérique virtuel correspondant (votre deuxième disque, par exemple).Dans cet esprit, lorsqu'il arrive à la partie lue , il traite tous les enfants (qu'ils soient en miroir ou blocs identiques) comme potentiellement dangereux s'il ne contient pas le contenu attendu
good_copies, et les réécrit au besoin . Il semble donc que la réponse à votre question soit - oui, il les réécrira lorsque vous aurez au moins une bonne copie, et l'une des options suivantes:Phew! Peut-être que quelqu'un peut signaler des défauts, mais j'ai apprécié l'apprentissage de ZFS à travers ce petit exercice, et j'espère que cela vous aidera!
la source
@jlliagre et d'autres qui semblent penser que le zpool entier meurt si l'un des disques (vdevs) meurt mais que le pool n'est pas redondant (mirror / raidz). Ce n'est pas vrai; un pool multi-disques survivra toujours à une seule défaillance complète du disque même s'il ne s'agit pas d'un miroir ou d'un raidz.
Les métadonnées ZFS sont toujours copiées au moins 2 fois, de sorte que la défaillance totale d'un disque complet (ou d'une partie de celui-ci) ne supprimera pas le système de fichiers. De plus, de nombreux fichiers, en particulier les plus petits, ne seront pas répartis sur tous les disques et ne seront donc pas nécessairement défaillants par la défaillance du disque. L'OP pose des questions sur le cas d'un pool multi-disques utilisant des blocs idem (copies de données utilisateur> 1). Ici, une seule défaillance complète du disque ne
devrait jamais entraîner de perte de données.ZFS essaiera toujours de placer les blocs idem loin du bloc d'origine, et pour les pools avec plusieurs vdev, cela signifie toujours sur un autre vdev (une exception pourrait être lorsqu'un vdev représente> 50% du pool, ce qui serait très inhabituel) . Les métadonnées du système de fichiers sont également toujours copiées +1 ou +2 fois plus que le niveau idem, de sorte qu'elles survivront toujours à la défaillance du disque. De plus, si vous disposez d'un pool de plus de trois disques, vous devriez pouvoir en perdre jusqu'à la moitié sans perte de données; ZFS stocke les blocs idem sur le disque suivant afin que tant que vous ne perdez jamais deux disques adjacents, vous n'aurez jamais de perte de données. (trois pannes de disque consécutives pour idem = 2).Lorsqu'il y a suffisamment de copies de données pour accéder à un fichier (que ces copies proviennent de blocs idem, miroir ou raidz), toutes les copies de données manquantes sont réparées lors de l'accès au fichier. C'est le but du gommage; lire toutes les données et corriger celles qui sont mauvaises en utilisant des copies redondantes. Donc, pour répondre directement à la question OP, il vous suffit de faire un nettoyage après avoir remplacé le disque défectueux, et toutes les copies seront restaurées.
Comme toujours, vous pouvez facilement expérimenter les concepts en créant des pools dont les vdev pour le magasin de sauvegarde ne sont que des fichiers épars ordinaires. En supprimant ou en corrompant les fichiers vdev, vous pouvez simuler tout type de panne et vérifier l'intégrité du pool, des systèmes de fichiers et des données en cours de route.
EDIT: après l'expérimentation, il semble que zfs échoue dans le pool si un disque tombe en panne dans un pool multi-disques non redondant avec des copies> = 2. La corruption des données paritaires sur un ou plusieurs disques doit pouvoir survivre et être corrigée par un nettoyage.
la source