12 février 2015

gluster

Gestionnaire gluster

Commandes

volume info [all|‹VOLNAME›] Affiche des informations sur tous les volumes, ou le volume spécifié
volume create ‹NEW-VOLNAME› [stripe ‹COUNT›] [replica ‹COUNT›] [disperse [‹COUNT›]] [redundancy ‹COUNT›] [transport ‹tcp|rdma|tcp,rdma›] ‹NEW-BRICK› ... Crée un nouveau volume.
volume delete ‹VOLNAME› Supprime le volume spécifié
volume start ‹VOLNAME› Démarre le volume spécifié
volume stop ‹VOLNAME› [force] Arrête le volume spécifié
volume rename ‹VOLNAME› ‹NEW-VOLNAME› Renomme le volume spécifié
volume set ‹VOLNAME› ‹OPTION› ‹PARAMETER› [‹OPTION› ‹PARAMETER›] ... Définis les options du volume
volume get ‹VOLNAME› ‹OPTION/all› Afficher les options du volume

Commandes de briques

volume add-brick ‹VOLNAME› ‹NEW-BRICK› ... Ajoute le brick spécifié au volume spécifié
volume remove-brick ‹VOLNAME› ‹BRICK› ... Supprime le brick spécifié
volume replace-brick ‹VOLNAME› ‹SOURCE-BRICK› ‹NEW-BRICK› commit force Remplace le brick spécifié
volume rebalance ‹VOLNAME› start Démarre la re-balance du volume spécifié
volume rebalance ‹VOLNAME› stop Stope la re-balance du volume spécifié
volume rebalance ‹VOLNAME› status Affiche le status de re-balance du volume spécifié

Commandes des logs

volume log filename ‹VOLNAME› [BRICK] ‹DIRECTORY› Répertoire de log pour le volume/brick correspondant
volume log locate ‹VOLNAME› [BRICK] Localise le répertoire de logs
volume log rotate ‹VOLNAME› [BRICK] Effectue une rotation des fichier de logs

Commandes de paires

peer probe ‹HOSTNAME› Cherche et ajoute le pair spécifié.
peer detach ‹HOSTNAME› Détache le pair spécifié
peer status Affiche le status des pairs

Commandes tier

volume tier ‹VOLNAME› attach [‹replica COUNT›] ‹NEW-BRICK›... Attache à un volume existant un tier du type spécifié en utilisant les bricks spécifiés
volume tier ‹VOLNAME› status Affiche des statistiques sur la migration des données entre les tiers chaud et froid
volume tier ‹VOLNAME› detach start Détache le tier chaud du volume. Les données sont déplacées du tier chaud vers le tier froid
volume tier ‹VOLNAME› detach commit [force] Sousmet un détachement du tier chaud du volume. Le volume revient à son état d'origine avant que le tier chaud ne soit attaché
volume tier ‹VOLNAME› detach status Afficher le status du mouvement des données
volume tier ‹VOLNAME› detach stop Arrête de détacher le tier chaud du volume

Commandes Geo-replication

volume geo-replication ‹MASTER_VOL› ‹SLAVE_HOST›::‹SLAVE_VOL› create [push-pem] [force] Créer une nouvelle session de geo-réplication.
volume geo-replication ‹MASTER_VOL› ‹SLAVE_HOST›::‹SLAVE_VOL› {start|stop} [force] démarre/arrête la session de geo-replication.
volume geo-replication [‹MASTER_VOL› [‹SLAVE_HOST›::‹SLAVE_VOL›]] status [detail] Affiche le status de la session de geo-replication
volume geo-replication ‹MASTER_VOL› ‹SLAVE_HOST›::‹SLAVE_VOL› {pause|resume} [force] Pause/relance la session de geo-replication
volume geo-replication ‹MASTER_VOL› ‹SLAVE_HOST›::‹SLAVE_VOL› delete [reset-sync-time] Détruire une session de geo-replication. reset-sync-time réinitialise le délai de synchro.
volume geo-replication ‹MASTER_VOL› ‹SLAVE_HOST›::‹SLAVE_VOL› config [[!]‹options› [‹value›]] voir ou définis la configuration pour la session de geo-replication

Commandes bitrot

volume bitrot ‹VOLNAME› {enable|disable} active/désactive le bitrot pour le volume
volume bitrot ‹VOLNAME› scrub-throttle {lazy|normal|aggressive} la valeur scrub-throttle est une mesure sur la rapidité du scrubs de système de fichier
volume bitrot ‹VOLNAME› scrub-frequency {daily|weekly|biweekly|monthly} Fréquence du scrubing
volume bitrot ‹VOLNAME› scrub {pause|resume|status|ondemand} paume/relance le scrub

commandes de snapshots

snapshot create ‹snapname› ‹volname› [description ‹description›] [force] Créé un snapshot d'un volume glusterfs.
snapshot restore ‹snapname› Applique un snapshot à un volume glusterfs
snapshot delete ( all | ‹snapname› | volume ‹volname› ) Supprime un snapshot
snapshot clone ‹clonename› ‹snapname› Clone un volume snapshot
snapshot list [volname] Liste les snapshots d'un volume
snapshot info [snapname | (volume ‹volname›)] Affiche des informations sur un snapshot
snapshot status [snapname | (volume ‹volname›)] Donne le status d'un snapshot
snapshot config [volname] ([snap-max-hard-limit ‹count›] [snap-max-soft-limit ‹percent›]) | ([auto-delete ‹enable|disable›]) | ([activate-on-create ‹enable|disable›]) Affiche et définis les valeurs de configuration d'un snapshot. Possède les options suivantes:

snap-max-soft-limit ‹count› option globale.
snap-max-soft-limit ‹percent› option globale
auto-delete ‹enable|disable› option globale. permet de conserver snap-max-soft-limit snapshots au maximum
activate-on-create ‹enable|disable› active le snapshot à la création

snapshot activate ‹snapname› Active le snapshot spécifié.
snapshot deactivate ‹snapname› Désactive le snapshot spécifié

Commande heal

volume heal ‹VOLNAME› déclenche l'indexe de réparation pour les fichiers qui doivent être réparés
volume heal ‹VOLNAME› [enable|disable] Active/désactive le service d'auto-réparation pour le volume
volume heal ‹VOLNAME› full Déclenche l'auto-réparation sur tous les fichiers
volume heal ‹VOLNAME› info Liste les fichiers qui doivent être réparés
volume heal ‹VOLNAME› info split-brain Liste les fichiers sont à l'état split-brain
volume heal ‹VOLNAME› statistics Affiche les statistiques
volume heal ‹VOLNAME› statistics heal-count Affiche le compteur de fichiers à réparer
volume heal ‹VOLNAME› statistics heal-count replica ‹HOSTNAME:BRICKNAME› Affiche le nombre de fichiers à réparer depuis un sous-volume réplica particulier auquel le brick ‹HOSTNAME:BRICKNAME› appartient
volume heal ‹VOLNAME› split-brain bigger-file ‹FILE› Répare le fichier qui est en état split-brain en choisissant le plus gros fichier dans le réplica
volume heal ‹VOLNAME› split-brain source-brick ‹HOSTNAME:BRICKNAME› Sélectionne ‹HOSTENAME:BRICKNAME› comme source pour tous les fichiers qui sont en split-brain dans ce réplica et les répare
volume heal ‹VOLNAME› split-brain source-brick ‹HOSTNAME:BRICKNAME› ‹FILE› Sélection le fichier à l'état split-brain comme source et complète la réparation

Autres commandes

get-state [‹daemon›] [odir ‹/path/to/output/dir/›] [file ‹filename›] Affiche l'état du service mentionné et stocke les données à l'emplacement spécifié

22 mai 2016

md

Pilote Multiple Device

   Le pilote md fournis des périphériques virtuels qui sont créés depuis un ou plusieurs périphériques indépendants. Cet array de périphériques contient souvent une redondance et les périphériques sont souvent des périphériques disques.

   md supporte les RAID niveau 1 (mirroring), 4 (striped avec parité), 5 (striped avec parité distribué), 6 (striped avec double redondance), et 10 (striped et mirroré). Si un périphérique échoue en utilisant un de ces levels, l'array contitue de fonctionner.

   md supporte également les configurations pseudo-raid (non-redondants) incluant le raid0 (striped array), linear (array sérialisé), multipath (un jeu de différentes interfaces vers le même périphérique) et faulty (une couche sur un simple périphérique dans lequel les erreurs sont injectés).

Métadonnées MD

   Chaque périphérique dans un array peut avoir des métadonnées stockées dans le périphérique. Ces métadonnées sont parfois appelés superblock. Les métadonnées enregistrent des informations sur la structure et l'état de l'array pour pouvoir ré-assembler l'array après un arrêt.

   Depuis la version 2.6.10 du Kernel, md fournis le support pour 2 formats différents de métadonnées, et d'autres formats peuvent être ajoutés.

   Le format commun, la version 0.90, a un superblock qui fait 4ko et est écrit dans un block aligné sur 64Ko qui démarre au plus 64K et moins de 128k de la fin du périphérique (ex, pour obtenir l'adresse du superblock arrondir la taille du périphérique à un multiple de 64K, puis soustraire 64K). La taille disponible pour chaque périphérique est la quantité d'espace avent le superblock, dont entre 64K et 128K est perdu quant un périphérique est incorporé dans un array MD. Ce superblock stock les champs multi-octet de manière indépendante su processeur, pour que les array puissent être déplacés entre des machines de différents processeurs.

   Le nouveau format, version 1, a un superblock qui fait normalement 1K de long, mais peut faire plus. Il est normalement stocké entre 8K et 12k de la fin du périphérique, sur un alignement 4K, bien de des variante peuvent être stockées au début du disque (version 1.1) ou à 4K du début du périphérique (version 1.2). Ce format de métadonnées stocke les données multi-octets dans un format indépendant du processeur et supporte des centaines de périphériques contre 28 pour les versions 0.90.

   Les métadonnées contiennent, entre autre:

LEVEL Le type d'array
UUID Un identifiant 128bits unique qui identifie l'array

   Quand une versions 0.90 est redéfinie (ex, ajout de péripériques dans un raid 5), le numéro de version est temporairement mis à 0.91. Celà permet de s'assurer que le processus s'est terminé correctement.

Métadonnées sans arrays

Bien qu'il est recommandé de créer des array avec des superblocks pour qu'ils puissent être réassemblés correctement, il y a certaines circonstances où un array sant superblock est préférrable:

LEGACY ARRAY Les première versions du pilote md ne supportent que les configuration LINEAR et RAID0 et n'utilise pas de superblock (qui est moins critique dans ces configuration).
FAULTY Ce type ne tire aucun bénéfice d'un superblock
MULTIPATH Il est souvent possible de détecter les périphériques qui sont des chemins différents du même stockage directement au lieu d'avoir un superblock distinct. Dans ce cas, un array multipath sans superblock a du sens.
RAID1 Dans certaines configurations il peut être souhaitable de créer une configuration raid1 sans superblock, pour maintenir l'état de l'array n'importe où.

Métadonnées externes

   Depuis le kernel 2.6.28, le pilote md supporte les arrays avec des métadonnées externe. C'est à dire que les métadonnées ne sont pas gérés par le kernel mais par un programme de l'espace utilisateur. Cela permet de supporter différents formats de métadonnées.

   md est capable de communiquer avec le programme externe via différents attributs sysfs pour qu'il puisse effectuer les changements appropriés - par exemple, pour marquer un périphérique comme étant en faute. Si nécessaire, md attend que le programme prenne connaissance de l'événement en écrivant dans un attribut sysfs. la man mdmon(8) contient des détails sur cette intéraction.

   Conteneurs

LINEAR

Un array LINEAR sérialise simplement l'espace disponible de chaque lecteur pour former un grand disque virtuel. L'avantage de cet arrangement par rapport au raid0 est que l'array peut être configuré plus tard sans perturber les données dans l'array.

RAID0

Un raid0 est également connu comme array striped. Il est configuré à la création avec un taille de shunk qui doit être une puissance de 2, et au moins 4 KiO. Le premier chunk est assigné au premier disque, le second au deuxième disque, etc. Cette collection de chunk forment un stripe. Si les périphériques dans l'array n'ont pas tous la même taille, une fois le plus petit disque remplis, le pilote collecte les chunks en stripes plus petits.

RAID1

Un raid1 est également connus comme un jeu mirroir. Une fois initialisé, chaque périphérique dans un raid1 devrait avoir la même taille. Si ce n'est pas le cas, seul la quantité d'espace disponible sur le plus petit périphérique est utilisé.

Noter que la lecture balancé faite par le pilote n'améliore pas les performance comme un raid0. Les périphériques individuels dans un raid1 peuvent être marqués 'write-mostly'. Ces lecteurs sont exclus de la lecture balancée et seront lus seulement s'il n'y a pas d'autre option. Peut être utile pour des périphériques connectés sur un lien lent.

RAID4

Un raid4 est similaire à un RAID0 avec un périphérique suplémentaire pour stocker la parité. Ce périphérique est le dernier des périphériques actifs dans l'array. à la différence de raid0, raid4 nécessite également que tous les stripes disques, donc l'espace supplémentaire sur les disques plus grand que le plus petit est perdu.

Cela permet à l'array de continuer de fonctionner si un disque échoue.

RAID5

Similaire au raid5, mais les blocks de parités pour chaque stripe est distribué sur tous les périphériques. Cela permet plus de parallelisme dans les écritures. Il y a également plus de parallélisme pendant les lecture.

RAID6

Similaire au raid5, mais peut gérer la perte de 2 périphériques sans perte de données. Nécessite N+2 disques. Les performances d'un raid6 est légerement inférieur à un raid5 en mode simple disque d'erreur, et très lent pour un mode double disque d'erreur.

RAID10

Fournis une combinaison de raid1 et raid0, et parfois appelé raid1+0. Chaque block de données est dupliqué un certain nombre de fois, et la collection résultante de ces blocks sont distribués sur plusieurs disques.

En configurant un raid10, il est nécessaire de spécifier le nombre de réplicas de chaque block de données qui sont requis (généralement 2) et si leur layout est 'near', 'far' ou 'offset'

Exemples de layout raid10

   Les exemples ci-dessous visualisent la distribution de chunk dans les périphériques sous-jacents pour le layout.

   Pour simplifier il est assumé que la taille des chunks est égal à la taille des blocks des périphériques sous-jacents tout comme ceux du périphérique RAID10 exporté par le kernel.

   Les nombres décimaux (0, 1, 2, ...) sont les chunks du RAID10 et donc également des blocks et adresse de blocks du périphérique raid exporté

Layout "near" Quand des réplicas 'near' sont choisis, les copies multiples d'un chunk donné sont disposés consécutivement (aussi proche les uns des autres que possible) dans les stripes de l'array.

Avec un nombre paire de périphériques, ils sont probablement être au même offset sur les différents périphériques. C'est le raid1+0 classique; c'est à dire 2 groupes de périphériques mirrorés. Dans l'exemple ci-dessous, les groupes de périphériques #1 / #2 et #3 / #4 sont des raid1, formant un raid0.
______|- - - - - -|- - - - - -|- - - - - -|- - - - - -|
______|_Device_#1_|_Device_#2_|_Device_#3_|_Device_#4_|
|- - -|- - - - - -|- - - - - -|- - - - - -|- - - - - -|
|0x00_|_____0_____|_____0_____|_____1_____|_____1_____|
|0x01_|_____2_____|_____2_____|_____3_____|_____3_____|
|...__|____...____|____...____|____...____|____...____|
|_:___|_____:_____|_____:_____|_____:_____|_____:_____|
|...__|____...____|____...____|____...____|____...____|
|0x80_|____254____|____254____|____255____|____255____|
|- - -|- - - - - -|- - - - - -|- - - - - -|- - - - - -|
________\- - - - -v- - - - -/___\- - - - -v- - - - -/_
________________RAID1___________________RAID1_________
________\- - - - - - - - - - -v- - - - - - - - - - -/_
____________________________RAID0_____________________

Exemple avec 2 copies par chunk et un nombre impaire de périphériques:
______|- - - - |- - - - |- - - - |- - - - |- - - - |
______|_Dev_#1_|_Dev_#2_|_Dev_#3_|_Dev_#4_|_Dev_#5_|
|- - -|- - - - |- - - - |- - - - |- - - - |- - - - |
|0x00_|___0____|___0____|___1____|___1____|___2____|
|0x01_|___2____|___3____|___3____|___4____|___4____|
|...__|__...___|__...___|__...___|__...___|__...___|
|_:___|___:____|___:____|___:____|___:____|___:____|
|...__|__...___|__...___|__...___|__...___|__...___|
|0x80_|__317___|__318___|__318___|__319___|__319___|
|- - -|- - - - |- - - - |- - - - |- - - - |- - - - |

Layout "far" Quand les réplicas far sont choisis, les copies d'un chunk sont disposés assez éloignés (aussi loin qu'il est raisonnablement possible)

   D'abord une séquence complète de tous les blocks de données (c'est à dire la données vues sur le périphériques blocks raid10 exporté) sont stripé sur les périphériques Puis une autre séquence (shift) complète de tous les blocks de données; et ainsi de suite

   Le shift nécessaire pour empêcher de placer les copies du même chunks sur les même périphériques est actuellement une permutation cyclique avec l'offset 1 de chaque stripes dans une séquence complet de chunks

L'offset 1 est relatif à la séquence complète précédente de chunks, donc en cas de plus de 2 copies par chunk on obtient les offsets suivantes:
1. Séquence complète de chunks: offset = 0
2. Séquence complète de chunks: offset = 1
3. Séquence complète de chunks: offset = 2
...
n. complete sequence of chunks: offset = n-1

Exemple avec 2 copies par chunk et un nombre paire de périphériques:
______|- - - - - -|- - - - - -|- - - - - -|- - - - - -|
______|_Device_#1_|_Device_#2_|_Device_#3_|_Device_#4_|
|- - -|- - - - - -|- - - - - -|- - - - - -|- - - - - -|
|0x00_|_____0_____|_____1_____|_____2_____|_____3_____|_\
|0x01_|_____4_____|_____5_____|_____6_____|_____7_____|_›_[#]
|...__|____...____|____...____|____...____|____...____|_:
|_:___|_____:_____|_____:_____|_____:_____|_____:_____|_:
|...__|____...____|____...____|____...____|____...____|_:
|0x40_|____252____|____253____|____254____|____255____|_/
|0x41_|_____3_____|_____0_____|_____1_____|_____2_____|_\
|0x42_|_____7_____|_____4_____|_____5_____|_____6_____|_›_[#]~
|...__|____...____|____...____|____...____|____...____|_:
|_:___|_____:_____|_____:_____|_____:_____|_____:_____|_:
|...__|____...____|____...____|____...____|____...____|_:
|0x80_|____255____|____252____|____253____|____254____|_/
|- - -|- - - - - -|- - - - - -|- - - - - -|- - - - - -|

Exemple avec 2 copies par chunk et un nombre impaire de périphériques:
______|- - - - |- - - - |- - - - |- - - - |- - - - |
______|_Dev_#1_|_Dev_#2_|_Dev_#3_|_Dev_#4_|_Dev_#5_|
|- - -|- - - - |- - - - |- - - - |- - - - |- - - - |
|0x00_|___0____|___1____|___2____|___3____|___4____|_\
|0x01_|___5____|___6____|___7____|___8____|___9____|_›_[#]
|...__|__...___|__...___|__...___|__...___|__...___|_:
|_:___|___:____|___:____|___:____|___:____|___:____|_:
|...__|__...___|__...___|__...___|__...___|__...___|_:
|0x40_|__315___|__316___|__317___|__318___|__319___|_/
|0x41_|___4____|___0____|___1____|___2____|___3____|_\
|0x42_|___9____|___5____|___6____|___7____|___8____|_›_[#]~
|...__|__...___|__...___|__...___|__...___|__...___|_:
|_:___|___:____|___:____|___:____|___:____|___:____|_:
|...__|__...___|__...___|__...___|__...___|__...___|_:
|0x80_|__319___|__315___|__316___|__317___|__318___|_/
|- - -|- - - - |- - - - |- - - - |- - - - |- - - - |

   Avec [#] étant la séquence complète de chunks et [#]~ la permutation cyclique avec l'offset 1 (dans le cas de plus de 2 copies par chunk ce serait ([#]~)~, (([#]~)~)~, ...)

   L'avantage de ce layout est que MD peut facilement propager les lectures séquentiellement sur le périphériques, les rendant similaire au raid0 en terme de vitesse. Les écriture en revenche sont plus lents

Layout offset Quand des réplicas offset sont choisis, toutes les copies d'un chunk donné sont stripé consécutivement (offset par la longueur du stripe avec chacun d'entre eux) sur les périphériques.

   Expliqué en détail, les chunks consécutif sont stripés sur les périphériques, immédiatement suivis par une copie décalée de ces chunk. Ce motif se répète pour tous les chunks consécutifs suivant.

   Le shift est nécessaire pour empêcher de placer les copies des même chunks sur le même périphérique avec une permutation de 1 de chaque copie stripée de chunks consécution.

L'offset 1 est relatif à la copie précedente, donc dans le cas de plus de 2 copies par chunk on obtient:
1. chunks consécutifs ‹nombre de périphériques›: offset = 0
2. chunks consécutifs ‹nombre de périphériques› = 1
3. chunks consécutifs ‹nombre de périphériques› = 2
...
n. chunks consécutifs ‹nombre de périphériques› = n-1

Exemple avec 2 copies par chunk et un nombre paire de périphériques:
______|- - - - - -|- - - - - -|- - - - - -|- - - - - -|
______|_Device_#1_|_Device_#2_|_Device_#3_|_Device_#4_|
|- - -|- - - - - -|- - - - - -|- - - - - -|- - - - - -|
|0x00_|_____0_____|_____1_____|_____2_____|_____3_____|_)_AA
|0x01_|_____3_____|_____0_____|_____1_____|_____2_____|_)_AA~
|0x02_|_____4_____|_____5_____|_____6_____|_____7_____|_)_AB
|0x03_|_____7_____|_____4_____|_____5_____|_____6_____|_)_AB~
|...__|____...____|____...____|____...____|____...____|_)_...
|_:___|_____:_____|_____:_____|_____:_____|_____:_____|___:
|...__|____...____|____...____|____...____|____...____|_)_...
|0x79_|____251____|____252____|____253____|____254____|_)_EX
|0x80_|____254____|____251____|____252____|____253____|_)_EX~
|- - -|- - - - - -|- - - - - -|- - - - - -|- - - - - -|

Exemple avec 2 copies par chunk et un nombre impaire de périphériques:
______|- - - - |- - - - |- - - - |- - - - |- - - - |
______|_Dev_#1_|_Dev_#2_|_Dev_#3_|_Dev_#4_|_Dev_#5_|
|- - -|- - - - |- - - - |- - - - |- - - - |- - - - |
|0x00_|___0____|___1____|___2____|___3____|___4____|_)_AA
|0x01_|___4____|___0____|___1____|___2____|___3____|_)_AA~
|0x02_|___5____|___6____|___7____|___8____|___9____|_)_AB
|0x03_|___9____|___5____|___6____|___7____|___8____|_)_AB~
|...__|__...___|__...___|__...___|__...___|__...___|_)_...
|_:___|___:____|___:____|___:____|___:____|___:____|___:
|...__|__...___|__...___|__...___|__...___|__...___|_)_...
|0x79_|__314___|__315___|__316___|__317___|__318___|_)_EX
|0x80_|__318___|__314___|__315___|__316___|__317___|_)_EX~
|- - -|- - - - |- - - - |- - - - |- - - - |- - - - |

   Avec AA, AB, ..., AZ, BA, ... étant le jeu de ‹nombre de périphériques› consécutifs de chunks et AA~, AB~, ..., AZ~, BA~, ... la permutation cyclique avec l'offset 1 (dans le cas de plus de 2 copies par chunk, il y aura (AA~)~, ... et ((AA~)~)~, ... et ainsi de suite)

   Cela donne des caractéristiques de lecture similaires à far, mais plus adapté à de grandes tailles de chunk, sans autant d'écritures.

   Il devrait être noté que le nombre de périphériques dans un raid10 n'a pas besoin d'être un multiple du nombre de réplica de chaque block de données; cependant, il doit y avoir au moins autant de périphériques que de réplicas

   Si, par exemple, un array est créé avec 5 périphériques et 2 réplicas, alors un espace équivalent à 2,5 périphériques sera disponible, et chaque block sera stocké sur 2 périphériques différents.

   Finalement, il est possible d'avoir un array avec des copies à la fois near et far. Si un array est configuré avec 2 copies near et 2 copies far, il y aura un total de 4 copies de chaque block, chacun sur un disque différent.

MULTIPATH MULTIPATH n'est pas vraiment un RAID vu qu'il n'y a qu'un disque physique dans un array md MULTIPATH. Cependant il y a plusieurs points d'accès à ce périphérique, et un de ces chemins peut échouer, donc il y a quelques similarités.

   Un array MULTIPATH est composé d'un nombre de périphériques logiquement différents, souvent des interfaces fibre qui réfèrent tous au même périphérique. Si une de ces interfaces échoue (ex: dûs à un problème de cable), le pilote va tenter de rediriger les requêtes vers une autre interface.

   Le disque MULTIPATH ne reçoit plus de développement et ne devrait pas être utilisé.

FAULTY Le module md FAULTY est fournis dans un but de tests. Un array FAULTY a exactement un périphérique et est normalement assemblé sans superblock, dont l'array créé fournis un accès directe à toutes les données dans le périphérique.

   Le module FAULTY peut être requis pour simuler des fautes pour permettre de tester d'autres niveaux md ou systèmes de fichier. Les fautes peuvent être choisies pour se déclencher sur des requêtes de lecture, et peut être transitoires ou persistantes.

Arrêt non propre

   Quand des changements sont fait sur un array RAID1/4/5/6/10 il y a une possibilité d'inconsistance pour de courtes périodes de temps vu que chaque mise à jours nécessite d'écrire au moins 2 blocks sur différents périphériques, et ces écritures peuvent ne pas se produire au même moment. Donc si un système avec un de ces array est éteind au milieu d'une opération d'écriture, l'array peut être inconsistant.

   Pour gérer cette situation, le pilote md marque l'array 'dirty' avant d'écrire une donnée, et le marque 'clean' quan l'array est désactivé à l'extinction. Si le pilote md trouve un array dirty au démarrage, il procède à une correction. Pour RAID1, cela implique de copier le contenu du premier disque dans tous les autres. Pour RAID4/5/6, cela implique de recalculer la parité pour chaque stripe et de s'assurerque le block de parité a une valeur correcte. Pour RAID10 cela implique de copier un des réplicas de chaque block dans tous les autres. Ce processus de resynchronisation est effectue en tâche de fond. L'array peut être utilisé pendant ce temps, mais possiblement avec des performances réduites.

   Si un RAID4/5/6 est dégradé (il manque au moins un disque, 2 pour un raid6) quand il est redémarré après un arrêt non propre, il ne peut pas recalculer la parité, et des données corrompues peuvent ne pas être détectés. Le pilote md ne démarrera pas si un array dans ces condition sans intervention manuelle, bien que ce comportement peut être changé par un paramètre kernel.

Récupération

   Si le pilote md détecte une erreur d'écriture sur un périphérique dans un RAID1/4/5/6/10, il désactive immédiatement le périphérique (marqué faulty) et continue ses opérations sur les autres disques. Il y a un disque spare, le pilote va démarrer le re-création sur un des disques spare.

   Dans le kernel, une erreur de lecture force md à ne pas tenter de récupérer un mauvais block, ex, il va trouve la donnée correcte quelque-part, écrire sur le block défectueux, puis tenter de lire ce block de nouveau. Si l'écriture ou la re-lecture échoue, md traite l'erreur de la même manière qu'une erreur d'écriture est traitée, et échoue tout le périphérique.

   Quand ce processus de récupération se produit, md monitor l'accès à l'array et affiche le taux de récupération si d'autre activités se produisent, donc un accès normal à l'array n'est pas affecté. Quand une autre activité survient, le processus de récupération la traite à pleine vitesse. Les vitesses sont contrôlés avec 'speed_limit_min' et 'speed_limit_max'.

scrubbing et mismatches

   Vu que les périphériques de stockage peuvent développer de mauvais blocks à tout moment il est utile de lire régulièrement tous les blocks de tous les périphériques dans un array pour capturer ces blocks defectueux le plus tôt possible. Ce processus est appelé scribbing.

   Les arrays md peuvent être scrubbés en écrivant soit check ou repair dans le fichier md/sync_action dans le répertoire sysfs pour le périphérique.

   En demandant un scrub, md lit tous les block et vérifie la consistance des données. Pour raid1/10, cela signifie que les copies sont identiques. pour raid4/5/6 cela signifie que le block de parité est correcte.

   Si une erreur de lecture est détectée durant ce processus, le gestion d'erreur corrige les données. Dans de nombreux cas, cela corrige effectivement le mauvais block.

   Si tous les blocks sont lus avec succès mais apparaîssent inconsistants, ils sont considérés comme mismatch.

   Si 'check' a été utilisée, aucune action n'est prise pour gérer le mismatch, il est simplement enregistré. Si 'repair' est utilisé, un mismatch sera réparé de la même manière que resync répare les array. Pour raid5/6, de nouveaux blocks de parité sont écris. Pour raid1/10, tous sauf un block sont écrasés avec le contenu de ce block.

   Un compteur de mismatch est enregistré dans sysfs 'md/mismatch_cnt'. Il est mis à 0 quand un scrub commence et est incrémenté quand un secteur est trouvé qui est un mismatch, il ne détermine pas exactement combien de secteurs sont affectés mais ajoute simplement le nombre de secteurs dans l'unité IO qui été utilisé. Donc une valeur de 128 peut signifier qu'une vérification de 64Ko a trouvé une erreur (128*512o = 64Ko)

   Si un array est créé par mdadm avec --assume-clean alor une vérification ultérieure peut s'attendre à trouver des mismatch. Dans un raid5/6 propre, tout mismatch devrait indiquer un problème hardware.

   Cependant, sur un raid1/10 il est possible qu'il s'agisse d'un problème logiciel. Cela ne signifie pas nécessairement que les données dans l'array sont corrompues. Cela peut simplement signifier que le système ne s'occupe pas de ce qui est stocké sur cette partie de l'array - c'est de l'espace inutilisé.

   La cause principale de mismatch sur un raid0/10 se produit si une partition swap ou un fichier swap est stockés dans l'array.

   Quand le sous-système swap souhaite écrire une page de mémoire, il flag la page comme 'clean' dans le gestionnaire mémoire et demande au périphériques swap de l'écrire. Il est possible que la mémoire soit changée durant l'écriture dans le swap. Dans ce cas le flag 'clean' sera effacé une fois l'écriture complétée, et le sous-système swap va simplement oublier que le swapout a été tenté, et va possiblement choisir une page différente à écrire.

   Si le périphériques swap était sur un raid1/10, la donnée est envoyée de la mémoire vers de périphérique 2 fois, donc il est possible que la mémoire ait été changée entre temps. Ainsi, la valeur mismatch_cnt ne peut pas être interprété de manière sûre sur un raid1 ou raid10, notamment quand le périphérique est utilisé pour le swap.

Bitmap write-intent logging

   md supporte le log d'écriture basé sur bitmap. Si configuré, le bitmap est utilisé pour enregistrer quels blocks de l'array peuvent être désyncho. Avant toute requête d'écriture, md s'assure que le bit correspondant dans le log est mis. Après un délai sant écritures dans une zone de l'array, le bit correspondant est effacé.

   Ce bitmap est utilisé pour 2 optimisations:

   D'abord, après un arrêt non propre, le processus de resyncho va consulter le bitmap et seulement resynchroniser les blocks qui correspondent aux bits mis dans le bitmap. Cela peut considérablement réduire le temps de resynchro

   Ensuite, quand un lecteur échoue et est enlevé de l'array, md arrête d'effacer les bits dans les log. Si ce même disque est réajouté à l'array, md va le notifier et seulement récupérer les section du disque qui sont couverts par les bits mis dans le log. Cela peut permettre à un périphérique d'être temporairement enlevé puis réinséré sans causer de gros coûts de récupération.

   Le log d'écriture peut être stocké dans un fichier sur un périphérique séparé, ou peut être stocké près des superblocks d'un array qui a des superblocks. Il est possible d'ajouter un log à un array actif, ou de le supprimer.

Bad block list

   Chaque périphérique dans un array md peut stocker une liste de blocks défectueux connus. Cette liste a une taille de 4k et est généralement positionnée à la fin de l'espace entre le superblock et les données

   Quand un block ne peut pas être lu et ne peut pas être réparé en écrivant les données récupérées depuis les autres périphériques, l'adresse du block est stockée dans la liste des blocks défectueux. Similairement si une tentative d'écriture dans un block échoue, l'adresse sera enregistrée comme block défectueux. Si une tentative d'enregistrer le block défectueux échoue, tout le périphérique est marqué en erreur.

   Tenter de lire depuis un block défectueux génère une erreur de lecture. Tenter d'écrire dans un block défectueux connus est ignoré si des erreurs d'écriture ont été reportés par le périphérique. S'il n'y a pas d'erreur d'écriture, les données sont écrites dans le block et en cas de succès, l'adresse est supprimée de la liste.

Journal d'écriture RAID456

   Dû à la nature non-atomique des opérations d'écriture raid, d'interruption des opérations d'écriture (crash système, etc) sur un raid456 peut créer une inconsistance de parité et la perte de données. (également appelé RAID-5 write hole).

   md supporte l'écriture dans un journal. Quand l'array est créé, un périphérique journal additionnel peut être ajouté à l'array via l'option write-journal. Ce journal fonctionne comme les journaux des systèmes de fichier. Avant d'écrire les données sur disque, md écris les données et la parité du stripe dans le périphérique journal. Après un crash, md recherche dans le périphérique journal les opérations d'écritures incomplètes, et les écrit sur les disques.

   Quand le périphérique journal échoue, l'array est forcé en mode lecture-seule.

write-behind

md supporte write-behind sur les arrays RAID1. Cela permet à certains périphériques dans l'array d'être flaggé write-mostly. MD ne lit dans ces périphériques seulement s'il n'y a pas d'autres options. Si un bitmap write-intend est également fournis, les requêtes d'écriture vers les périphérique write-mostly sont traités comme des requêtes write-behind et md n'attend pas que les écritures soient complétées avant de reporter l'écriture complétée au système de fichier.

Cela permet à un RAID1 avec write-behind d'être utilisé comme donnée miroir sur un lien lent dans une machine distante. La latence supplémentaire de lien distant ne ralentira pas les opérations normales, mais le système distant continura à maintenir une copie raisonablement à jour de toutes les données

RESTRIPING

   re restriping, également appelé reshaping, est le processus de ré-arrangement des données stockées dans chaque stripe dans une nouvelle couche. Cela peut être dû au changement du nombre de disques dans l'array (donc les stripes sont plus long), changer la taille de chunk, ou changer l'arrangement des données et de la parité (possiblement changer le niveau de raid).

   md peut remodeler un raid4/5/6 pour avoir un nombre différent de disques et pour avoir un layout différent ou une taille de chunk différente. Il peut également convertir entre les différents niveaux de raid. Il peut également convertir entre raid0 et raid10, et entre raid0, raid4 ou raid5. D'autres possibilités peuvent suivre dans le future.

   Durant un traitement de stripe il y a une section critique durant lequel les données sont écrasées sur le disque. Pour l'opération d'augmentation du nombre de disques dans un raid5, cette section critique couvre les premier stripes (le nombre étant le produit de l'ancien et du nouveau nombre de disques). Une fois cette section critique passée, les données sont seulement écrite dans les aires de l'array qui ne maintient pas de données

   Pour un traitement qui réduit le nombre de périphériques, la section critique est à la fin du processus de reshaping.

   md n'est pas capable de s'assurer de la préservation des données s'il y a un crash durant la section critique. Si md doit démarrer un array qui a échoué durant une section critique, il refuse de démarrer l'array.

   Pour gérer ce cas, un programme userspace doit:

- désactiver les écritures dans cette section de l'array (en utilisant l'interface sysfs)
- Créer une copie des données
- permettre au processus de continuer et invalider l'accès en écriture au backup et restauration une fois la section critique passée
- fournir pour restorer les données critiques avant de redémarrer l'array après un crash.

   mdadm le fait pour les array raid5. Pour les opérations qui ne changent pas la taille de l'array, par exemple augmenter a taille de chunk, ou convertir un raid5 en raid6 avec un périphériques supplémentaire, tout le processus est la section critique. Dans ce cas, le restripe doit progresser en étapes, vu qu'une section est suspendue, backupée, restripée, et relachée.

Interface sysfs

Chaque périphériques block apparaît dans sysfs. Pour les périphériques MD, ce répertoire va contenir un sous-répertoire 'md' qui contient divers fichiers pour fournir l'accès aux informations sur l'array.

Cette interface est documentée dans Documentation/md.txt:

md/sync_speed_min Si définis, écrase le paramètre système dans /proc/sys/dev/raid/speed_limit_min pour cet array uniquement. La valeur 'system' force l'utilisation du paramètre système.
md/sync_speed_max Idem, pour /proc/sys/dev/raid/speed_limit_max
md/sync_action Peut être utilisé pour superviser et contrôler les processus de resynchro/récupération. Écrire check déclenche la vérification de la consistance de tous les blocks de données. Un compteur de problèmes est stocké dans md/mismatch_count. 'repair' peut être écrit pour vérifier et corriger les erreurs.
md/stripe_cache_size Seulement disponible pour un raid5/6. Enregistre la taille (en pages par périphérique) du cache de stripe qui est utilisé pour synchoniser toutes les opérations d'écriture dans l'array et toutes les opérations de lecture si l'array est dégradé. Défaut: 256 (de 17 à 32768). Augmenter cette valeur améliore les performances dans certaines situations, au prix d'une consommation mémoire système accrue (memory_consumed = system_page_size addentry articles autoadd autofind autoprod createalpha createbeta createdb createprod findentry fullpowa generator.php genhtml genman genmd gentex html insert man md pdf regen setfor setfor2 sql temp temp-new-pc tex threads ToDo nr_disks addentry articles autoadd autofind autoprod createalpha createbeta createdb createprod findentry fullpowa generator.php genhtml genman genmd gentex html insert man md pdf regen setfor setfor2 sql temp temp-new-pc tex threads ToDo stripe_cache_size)
md/preread_bypass_threshold Seulement disponible pour un raid5/6. Cette variable définis le nombre de fois que md effectue un full-stripe-write avant de servire un stripe qui nécessite une pré-lecture. défaut: 1 (de 0 à stripe_cache_size). À 0, maximise l'écriture séquentielle au prix de l'équité pour les threads qui effectuent de petites écritures ou des écritures aléatoires.

Paramètres kernel

raid=noautodetect Désactive l'auto-detection des array au boot. Si un disque est partitionné avec des partitions de style MSDOS, si une des 4 partitions primaires a le type 0xFD, cette partition est normalement inspectée pour voir si elle fait partie d'un array. Ce paramètre désactive cette détection.
raid=partitionable
raid=part Indique que les array auto-détectés devraient être créés comme arrays partitionnables, avec un numéro majeur différent des array non-partitionnables. Le numéro de périphérique est listé comme 'mdp' dans /proc/devices'
md_mod.start_ro=1
/sys/module/md_mod/parameters/start_ro md démarre tous les array en lecture seule. C'est un RO soft qui bascule automatiquement en lecture-écriture à la première requête d'écriture.
md_mod.start_dirty_degraded=1
/sys/module/md_mod/parameters/start_dirty_degraded ne démarre pas de raid4/5/6 qui est dégradé. Ce paramètre permet de forcer le démarrage de tels array au boot. (utile pour /)
md=n,dev,dev,...
md=dn,dev,dev,... Indique au pilote md d'assembler '/dev/md n' depuis les périphériques listés. Seulement nécessaire pour démarrer le périphérique maintenant le système de fichier racine.
md=n,l,c,i,dev... Indique au pilote md d'assembler un array RAID0 ou LINEAR dans superblock. 'n' donne le nombre de périphériques, 'l' donnele niveau (0=RAID0 ou -1=LINEAR), 'c' donne la taille de chunk en logarithme base-2 par 12, donc 0 indique 4k, 1 indique 8k. 'i' est ignoré.

Fichiers

/proc/mdstat Contient les informations sur le status de l'array en cours d'exécution
/proc/sys/dev/raid/speed_limit_min Reflète la vitesse courante de reconstruction quand l'activité de non-reconstruction est en cours dans un array. La vitesse est en Kio/s, et est un taux par périphérique. Défaut: 1000.
/proc/sys/dev/raid/speed_limit_max Reflète la vitesse courante de reconstruction quand aucune activité de non-reconstruction est en cours dans un array. Défaut: 200,000.

22 mai 2016

mdadm

Gestion de périphériques raid

Les périphériques RAID logiciel Linux sont implémentés via le pilote md (Multiple Devices). Actuellement, linux supporte les périphériques LINEAR, RAID0, RAID1, RAID4, RAID5, RAID6, RAID10, MULTIPATH, FAULTY, et CONTAINER

MULTIPATH N'est pas un mécanisme raid logiciel, mais implique des périphériques multiples: chaque périphérique est un chemin vers un stockage physique. Il ne devrait plus être utilisé
FAULTY N'est pas un mécanisme raid, et implique seulement 1 périphérique. Il fournis un couche sur un vrai périphérique qui peut être utilisé pour injecter des fautes
CONTAINER est différent, c'est une collection de périphériques qui sont gérés comme un set. C'est similaire à un jeu de périphériques connectés à un contrôleur RAID hardware. Le jeu de périphériques peut contenir plusieurs RAID, chacun utilisant certains ou tous les blocks dans certains périphériques du set. Par exemple, 2 périphériques d'un set de 5 périphériques peuvent former un RAID 1 en utilisant tout l'espace. Les 3 autres peut avoir un raid5 utilisant la moitie de chaque périphérique, et un raid0 pour la seconde moitié.

Modes

mdadm a de nombreux modes d'opérations:

assemble assemble les composants d'un array précédemment créé en un array actif.
build Construit un tableau sans superblocks.
create Créé un nouvel array avec superblocks.
follow
monitor supervise un ou plusieurs périphériques md et agit sur les changements d'état.
grow Agrandit ou réduit un array.
incremental assembly Ajoute un périphérique dans un array.
manage gérer un array, comme ajouter un nouveau spare, et supprimer a périphérique
misc mode qui fait toutes les autres opérations sur les array actifs tel qu'effacer les anciens superblocks.
auto-detect Demande au kernel d'activer tout les arrays auto-détectés

Options pour sélectionner un mode

-A, --assemble assemble un array existant
-B, --build Construit un array sans superblocks
-C, --create Créé un nouvel array
-F, --follow, --monitor Sélectionne le mode monitor
-G, --grow Change la taille d'un array actif
-I, --incremantal Ajoute/supprime un périphérique à un array
--auto-detect Demande au kernel de démarrer les array auto-détectés. ne fonctionne que si md est compilé dans le kernel (pas en module)

Si un périphérique est donné avant toute options, ou si la première option est --add, --re-add, --add-spare, --fail, --remove, ou --replace, le mode Manage est assumé.

Options non spécifique au mode

-v, --verbose mode verbeux
-q, --quiet Mode silencieu
-f, --force Force l'action
-c, --config= Spécifie le fichier de configuration ou le répertoire. Défaut: /etc/mdadm/mdadm.conf et /etc/mdadm/mdadm.conf.d/
-s, --scan Scanne la configuration ou /proc/mdstat pour les informations manquantes.
-e, --metadata= Déclare de style de métadonnées de raid à utiliser. Défaut: 1.2 pour --create:

0, 0.90 Utilise le format original 0.90. Ce format limite les array à 28 périphériques, et 2To.
1, 1.0, 1.1, 1.2 default Utilise le nouveau format.
ddf Utilise le format DDF (Disk Data Format) définis par SNIA. En créant un array DDF, un CONTAINER est créé.
imsm Utilise le format Intel Matrix Storage Manager. Cela créé un CONTAINER géré de manière similaire à DDF.

--homehost* Remplace tout paramètre HOMEHOST dans la configuration et fournis l'identité de l'hôte qui devrait être considéré le home de tous les arrays. cet homehost est enregistré dans les métadonnées.
--prefer= Quand mdadm a besoin d'afficher le nom d'un périphérique il le trouve normalement dans /dev. Quand un chemin est donné avec cette option, mdadm va préférer un nom plus long s'il contient un composant. par exemple --prefer-by-uuid va préférer un nom dans /dev/by-uuid/
--home-cluster= Spécifie le nom du cluster pour le périphérique md. Le périphérique md peut être assemblé seulement dans le cluster qui match le nom spécifié.

Options pour create, build, ou grow

-n, --raid-devices= Spécifie le nombre de périphériques actifs dans l'array, incluant les spare et ceux manquants
-x, --spare-devices= Spécifie le nombre de périphériques spare dans l'array initial
-z, --size= Espace en Kio à utiliser dans chaque disque dans le raid 1/4/5/6. Doit être un multiple de la taille de chunk, et doit laisser 128Kb à la fin du disque pour le superblock RAID.
-Z, --array-size= C'est seulement avec' --grow et son effet n'est pas persistant. Avec cette option, l'array paraît plus petit qu'il ne l'est.
-c, --chunk= Spécifie la taille de chunk en KiO. Défaut: 512KiO. Pour s'assurer de la compatibilité avec les anciennes versions, le défaut à la construction d'un array sans métadonnées persistantes est de 64Ko. C'est seulement significatif pour les raid 0/4/5/6/10. les raid 4/5/6/10 nécessitent un taille en puissance de 2. Dans tous les cas, doit être un multiple de 4Ko.
--rounding Spécifie le facteur d'arrondissement pour un array linéaire. La taille de chaque composant sera arrondi à un multiple de cette taille. Défaut: 0
-l, --level= Définis le niveau de raid. avec --create les options sont: linear, raid0, 0, stripe, raid1, 1, mirror, raid4, 4, raid5, 5, raid6, 6, raid10, 10, mulitpath, mp, faulty, container. Avec --build: linear, stripe, raid0, 0, raid1, multipath, mp, faulty.
-p, --layout=, --parity= Configure le détails de la couche de données pour les raid 5/6/10, et contrôle les modes d'erreur pour faulty. pour un raid5: left-asymmetric, left-symmetric, right-asymmetric, right-symmetric, la, ra, ls, rs. Défaut: left-symmetric. Il est également possible de forcer un raid5 à utiliser une couche raid4 avec parity-first ou parity-last. Pour les raid5 DDF, ddf-zero-restart, ddf-N-restart et ddf-N-contitue. Ces layouts sont également disponible pour le raid6. 4 layouts sont fournis en étape intermédiaire pour convertir un raid5 en raid6: left-symmetric-6, right-symmetric-6, left-asymmetric-6, right-asymmetric-6, et parity-first-6.

Pour faulty, les options sont: write-transient, wt, read-transient, rt, write-persistent, wp, read-persistent, rp, write-all, read-fixable, rf, clear, flush, none. Chaque mode d'erreur peut être suivi par un nombre, qui est utilisé comme période entre la génération d'erreurs. Pour les raid10: n, o, ou f, suivi par un nombre. Défaut: n2:

n (near copies) Plusieurs copie d'un block de données sont à un offset similaire dans différents périphériques
o (offset copies) Au lieur de dupliquer les chunks dans un stripe, tous les stripes sont dupliqués mais avec une rotation d'un périphérique pour que les blocks dupliqués soient sur différents périphériques.
f (far copies) Plusieurs copies ont des offsets différents. voir md(4) pour plus de détails.

-b, --bitmap= Spécifie un fichier où stocker un bitmap. Ce fichier ne devrait pas exister sauf si --force est donné. Le même fihier devrait être donné en assemblant l'array. Si le mot internal est donné, le bitmap est stocké avec les métadonnées dans l'array, et donc est répliqué sur tous les périphériques Si le mot none est donné avec le mode --grow, tout bitmap présent est supprimé. Is le mot clustered est donné, l'array est créé pour un environnement clusterisé Un bitmap est crée pour chaque nœud comme définis par le paramètre --nodes et sont stockés en interne
--bitmap-chunk= Définis la taille de chunk du bitmap. Chaque bit correspond à autant de Ko de stockage. En utilisant un bitmap basé sur un fichier, le défaut est d'utiliser la taille la plus petite qui fait au moins 4 et au plus 2^21 chunks
-W, --write-mostly Les périphériques listés dans une commande --build, --create, --add seront flaggés en write-mostly. raid1 uniquement et signifie que le pilote md évite de lire dans ces périphériques si possible. Peut être utile pour un mirroir sur un réseau lent.
--write-behind= Active le mode write-behind (raid1). Si un argument est spécifié, il définis le nombre max d'écritures arriéré permis. Défaut: 256. un bitmap write-extent est requis, et ce mode n'est tenté que sur les disques marqués write-mostly.
--assume-clean Dit à mdadm que l'array pré-existant est correct. peut être utile en tentant une récupération après une erreur majeur
--backup-file= Nécessaire avec --grow utilisé pour augmenter le nombre de périphériques dans un raid 5 ou 6 s'il n'y a pas de disque spare disponible, ou pour réduire, changer le niveau de raid ou le layout.
--data-offset= Les array avec des métadonnées 1.x peut laisser un espace entre le début d'un périphérique et le début des données. Normalement le début des données est calculé automatiquement, mais cette option permet de le spécifier manuellement
--continue Cette option est complémentaire à l'option --freeze-reshape pour assembly. Il est nécessaire quand l'opération --grow est interrompue et n'est pas redémarré automatiquement à cause de l'utilisation de --freeze-reshape durant l'assemblage de l'array.
-N, --name= Définis un nom pour l'array. Seulement effectif en créant un array avec un superblock version 1, ou un array dans un conteneur DDF.
-R, --run Insiste pour que mdadm lance l'array, même si certains composants apparaîssent actif dans un autre array ou système de fichier. Normalement, mdadm demande confirmation pour cela, cette option suprime la question.
-f, --force Insiste pour que mdadm accepte la géométrie et le layout spécifié sans question.
-o, --readonly Démarre l'array en mode lecture seule
-a, --auto{=yes,md,mdp,part,p}{NN} Instruit mdadm sur la manière de créer un fichier de périphérique si nécessaire, en allouant possiblement un numéro mineur non-utilisé. "md" utilise un array non-partitionnable, "mdp", "part" ou "p" utilise un array partitionnable. "yes" nécessite que le périphérique md ait le format standard. Depuis mdadm 3.0, la création de périphérique est effectuée par udev, donc cette option n'est pas nécessaire
-a, --add Peut être utilisé en mode grow dans 2 cas. Il l'array cible est un array linear, --add peut être utilisé pour ajouter un ou plusieurs périphériques. Si l'option --raid-disks est utilisé pour augmenter le nombre de périphériques dans un array, --add peut être utilisé pour ajouter des périphériques supplémentaire à inclure dans l'array.
--nodes Ne fonction que lorsque l'array est pour un environnement clusterisé. Il spécifie le nombre max de nœuds dans le cluster qui vont utiliser ce périphérique simultannément. Défaut: 4
--write-journal Spécifie un périphérique journal pour l'array raid 4/5/6. Devrait être un SSD avec une durée de vie raisonnable

Options pour l'assemblage

-u, --uuid= uuid de l'array à assembler. Les périphériques qui n'ont pas cet uuid sont exclus
-m, --super-minor= numéro mineur du périphérique créé. Les périphériques qui n'ont pas ce numéro mineur sont exclus.
-N, --name= Spécifie le nom de l'array à assembler.
-f, --force Assemble l'array même si les métadonnées dans certains périphériques apparaîssent périmés.
-R, --run Tente de démarrer l'array même si moins de disques sont donné que la dernière fois qu'il a été actif.
--no-degraded Inverse de --run. Ne démarre que si tous les disques attendus sont présents.
-a, --auto{=yes,md,mdp,part,p}{NN} Voir plus haut
-b, --bitmap= Spécifie le fichier bitmap qui a été donné à la création de l'array.
--backup-file= Si utilisé pour re-définir un array (changer le nombre de périphériques, ou la taille de chunk) et que le système crash durant la section critique, cette option doit également être présent avec --assemble pour permettre à des données possiblement corrompus d'être restaurées.
--invalid-backup Si le fichier nécessaire pour l'option ci-dessus n'est pas disponible, un fichier vide peut être donné avec cette option pour indiquer que le fichier backup est invalide. Dans ce cas les données qui étaient ré-arrangés au moment du crash peuvent être perdus irrévocablement, mais le reste de l'array peut être récupérable. Cette option devrait être utilisée quand dernier recours.
-U, --update= Met à jours le superblock dans chaque périphérique en assemblant l'array. L'argument donné peut être (sparc2.2, summaries, uuid, name, nodes, homehost, home-cluster, resync, byteorder, devicesize, no-bitmap, bbl, no-bbl, metadata, ou super-minor):

sparc2.2 Ajuste le superblock d'un array qui a été sur une machine Sparc tournant sur un Kernel 2.2 patché.
super-minor Met à jours le champ 'preferred minor' dans chaque superblock pour correspondre au numéro mineur de l'array à assembler.
uuid Change l'uuid de l'array
name Change le nom de l'array stocké dans le superblock. (superblock V1 uniquement)
nodes Change les nœuds de l'array comme stocké dans le superblock bitmap. Ne fonctionne que pour les environnements clusterisés
homehost Change le homehost enregistré dans le superblock. Pour les superblocks V0, c'est identique à uuid, pour V1, met à jours le nom
home-cluster Change le nom du cluster. Ne fonctionne que pour les environnements clusterisés
resync Marque l'array 'dirty' signifiant qu'une redondance dans l'array peut être incorrect, et force un resync
byteorder Permet de déplacer l'array entre des machines avec un byte-order différent.
summaries Corrige les sommaires dans le superblock. (compteurs de périphériques total, fonctionnels, actifs, en erreur, et spare)
devicesize S'applique au métadonnées 1.1 et 1.2, utile quand le périphérique a changé de taille.
metadata Fonction avec les métadonnées 0.90 et va le convertir en v1.0. L'array ne doit pas être durty ni write-intent bitmap
no-bitmap Peut être utilisé quand un array a un bitmap interne qui est corrompus. Ignore le bitmap interne
bbl Réserve l'espace dans chaque périphérique pour une liste de blocks défectueux, de 4k vers la fin du disque.
no-bbl Supprime toute réservation pour la liste de blocks défectueux. Si la liste contient des entrées, il échoue.

--freeze-reshape Utilisé dans les scripts de démarrage. Quand un array sous reshape est assemblé au boot, cette option stop le reshape après la section critique. Cela se produit avant l'opération de pivot du système de fichiers et évite de perdre le contexte du système de fichier. Le reshape peut être repris ultérieurement avec --continue de la commande grow.

Pour le mode Manage

-t, --test Sauf si une erreur sérieuse se produit, mdadm quitte avec le status 2 si aucun changements n'est fait dans l'array et 0 si au moins un changement a été fait.
-a, --add Périphériques listés à chaud. Si un périphérique apparaît avoir fait partie récemment d'un array, le périphérique est re-ajouté. En cas d'échec ou si le périphérique n'a jamais fait partie de l'array, le périphérique est ajouté comme hot-spare. Si l'array est dégradé, il démarre immédiatement la reconstruction des données sur ce spare.
--re-add Re-ajoute un périphérique qui a été précédemment supprimé de l'array. Si les métadonnées dans le périphérique reportent qu'il est un membre de l'array, et que le slot qui est utilisé est vacant, ce périphérique est ajouté à l'array à la même position. Cela va automatiquement récupérer les données de ce périphérique. Utilisé dans un array qui n'a pas de métadonnées, assume que la récupération basée sur bitmap est suffisante pour rendre le périphérique suffisamment consistant avec l'array. avec des métadonnées V1.x, peut être accompagné avec --update-devicesize, --update=bbl ou --update=no-bbl.
--add-spare Ajoute un périphérique spare. Similaire à --add excepté qu'il ne tente pas de --re-add avant.
-r, --remove Supprime les périphériques listés. Ils ne doivent pas être actifs.
-f, --fail, --set-faulty Marque les périphériques listés en faute.
--replace Marque les périphériques listés à remplacer. Tant qu'un spare est disponible, il reconstruit et remplace le périphérique marqué. C'est similaire à marquer le périphérique en faute, mais il reste en service durant le traitement de récupération.
--with Peut suivre une liste de périphériques --replace. Ces périphériques sont utilisés de préférence pour remplacer les périphériques. Ces périphériques doivent déjà être marqués spare dans l'array.
--write-mostly Les périphériques qui sont ajoutés ou re-ajoutés auront le flag 'write-mostly' mis. Seulement valide pour RAID1 et signifie que md évite toute lecture dans ces périphériques si possible
--readwrite Les périphériques qui sont ajoutés ou re-ajoutés auront le flag 'write-mostly' effacé.
--cluster-confirm Confirme l'existence du périphérique. Émis en réponse à une requête --add par un nœud dans un cluster. Quand un nœud ajoute un périphérique il envoie un message à tous les nœuds dans le cluster pour rechercher un périphérique avec un UUID. Cela traduit en une notification udev avec l'UUID du périphériques à ajouter et le numéro de slot. Le nœud reçevant doit acquiter ce message avec --cluster-confirm. Les arguments valides sont ‹slot›:‹devicename› dans le cas où le périphérique est trouvé ou ‹slot›:missing si non trouvé.

   Chacune de ces options nécessite que le premier périphérique listé est l'array sur lequel agir, et le reste sont les périphérique à ajouter, supprimer, marqué en faute, etc. les différentes opération peuvent être spécifiée pour différents périphériques (ex: mdadm /dev/md0 --add /dev/sda1 --fail /dev/sdb1 --remove /dev/sdb1 ).

   Si un array utilise un bitmap write-intent, les périphériques qui ont été supprimés peuvent être re-ajouté de manière à éviter une reconstruction complète et seulement mettre à jour les blocks qui ont été changés depuis qu'il a été supprimé. Pour les array avec des métadonnées persistantes (superblocks) c'est fait automatiquement. Pour les array créés avec --build, mdadm doit indiquer que ce périphérique a été supprimé récemment avec --re-add.

   Les périphériques peuvent seulement être supprimés d'un array s'ils ne sont pas actifs, par exemple, doivent être spare ou en faute. Pour supprimer un périphérique actif, il faut le marquer en faute avant.

Mode Misc

-Q, --query Examine un périphérique pour voir si c'est un périphérique md et si c'est un composant d'un array md.
-D, --detail Affiche les détails d'un ou plusieurs périphériques md
--detail-platform Affiche des détails sur les capacités RAID de la plateform (firmware/topologie hardware) pour un format de métadonnées donné. Sans argument, mdadm scanne tous les controleurs à la recherche de leur capacités. Sinon, mdadm ne regarde que le contrôleur spécifié par l'argument sous la forme d'un chemin absolus ou un lien (ex: /sys/devices/pci0000:00/0000:00:1f.2)
-Y, --export Avec --detail, --detail-platform, --examine, ou --incremental, la sortie est formatté en paire clé=valeur pour simpifier l'import dans l'environnement. MD_STARTED indique si un array a été démarré, qui peut inclure une raison. MD_FOREIGN indique si l'array est attendu sur cet hôte
-E, --examine Affiche le contenu des métadonnées stockés dans le(s) périphérique(s) spécifié(s). --examine s'applique aux périphériques qui sont des composants d'un array, alors que --detail s'applique à l'array actif.
--sparc2.2 Si un array a été créé sur une machine sparc avec un kernel 2.2 patché avec le support RAID, le superblock a été créé de manière incorrect, incompatible avec les kernel 2.4 et +. Cette option fix le superblock avant de l'afficher. Dans ce cas, on peut assembler avec --assemble --update=sparc2.2.
-X, --examine-bitmap Repporte les inforamtions sur le fichier bitmap. L'argument est soit un fichie bitmap externe, ou un composant array dans le cas d'un bitmap interne.
--examine-badblock Liste les blocks défectueux enregistrés dans un périphérique (métadata v1.x)
--dump=directory, --restore=directory Sauve les métadonnées d'une liste de périphériques, ou les restaure.
-R, --run Démarre un array partiellement assemblé. Si --assemble n'a pas suffisamment de périphériques pour démarrer l'array, cette option démarre l'array en mode dégradé.
-S, --stop Désactive un array
-o, --readonly Marque un array en lecture seule
-w, --readwrite Marque l'array en lecture écriture
--zero-superblock Si le périphérique contient un superblock md valide, le block est remplis de zéro. avec --force, le block œu ce superblock devrait être sera écrasé même s'il apparaît non valide
--kill-subarray= Si le périphérique est un conteneur et l'argument spécifie un sous-array inactif dans le conteneur, ce sous-array est supprimé. Supprimer tous les sous-array laisse un conteneur vide ou un superblock spare dans les disques. voir --zero-superblock pour supprimer complètement un superblock.
--update-subarray= Si le périphérique est un conteneur et l'argument spécifie un sous-array dans le conteneur, tente de mettre à jour le superblock doné dans le sous-array.
-t, --test Avec --detail, le code de sortie de mdadm est mis pour refléter le status du périphérique
-W, --wait Pour chaque périphérique md donné, attend la fin d'une resyncho, récupération, ou reshaping avant de quitter.
--wait-clean Pour chaque périphérique md doné ou chaque périphérique dans /proc/mdstat si --scan est donné, s'assure que l'array est marqué clean dès que possible.
--action= Définis le 'sync_action' pour tous les périphériques donné à idle, frozen, check ou repair. idle annule l'action en cours bien que certaines action vont redémarrer automatiquement. frozen annule l'action en cours et s'assur qu'aucune autre action ne démarre automatiquement.

Mode assemblage incrémental

--rebuild-map, -r Reconstruit le fichier de map (/run/mdadm/map) que mdadm utilise pour suivre les array actuellement assemblés
--run, -R Lance un array assemblé dès qu'un nombre minimum de périphériques sont disponibles.
--scan, -s avec -R, scan le fichier de map à la recherche d'array qui sont assemblés incrémentalement et tente de démarrer tous ceux qui ne sont pas déjà démarrés. Si un tel array est listé dans mdadm.conf comme nécessitant un bitmap externe, ce bitmap sera attaché avant.
--fail, -f Permet au système hotplug de supprimer les périphériques qui ont disparus complètement du kernel. Ils sont d'abord mis en faute, puis supprimés de l'array. Cela permet au périphérique en faute d'être automatiquement remplacé par un nouveau périphériques sans métadonnées s'il apparaît au chemin spécifié. Cette option est normallement définis seulement par un script udev.

Mode Monitor

-m, --mail Addresse mail où envoyer des alertes
-p, --program, --alert Programme à lancer quant un événements est détecté
-y, --syslog Tous les événements sont reportés via syslog. Les messages ont la facilité 'daemon'
-d, --delay Délay en seconde d'attente avant de resonder les arrays md. Défaut: 60 secondes. Il n'est pas nécessaire de réduire ce délai vu que le kernel alerte immédiatement mdadm en cas de changement.
-r, --increment mdadm génère des événements RebuildNN avec le % d'incrément donné
-f, --daemonise Lance mdadm en tâche de fond
-i, --pid-file quand mdadm est lancé en mode service, écris le pid du process dans le fichier spécifié
-1, --oneshot Vérifie les arrays seulement une fois. Cela génère des événements NewArray, DegradedArray et SparesMissing.
-t, --test Génère une alert TestMessage pour tout array trouvé au démarrage.
--no-sharing Inhibe la fonctionnalité pour déplacer les spares entre les arrays. Seul un processus de monitoring démarré avec --scan, mais sans ce flag est permis.

Mode ASSEMBLE

   Assemble un ou plusieurs arrays RAID depuis des composants pré-existants. Pour chaque array, mdadm doit connaître le périphérique md, l'identité de l'array, et des périphériques. Ils peuvent être trouvés de différentes manières.

   sans l'option --scan, le premier périphériques donné est le périphérique md. Avec --scan, tous les périphériques listés sont des périphériques md et un assemblage est tenté. Avec --scan, sans périphérique listé, tous les périphériques listés dans le fichier de configuration sont assemblés. Si aucun array n'est décris pas le fichier de configuration, les arrays qui peuvent être trouvé dans des périphériques non-utilisés seront assemblés

   Sans l'option --scan et avec exactement 1 périphérique donné, mdadm agit comme avec --scan et les informations d'identité sont extraits du fichier de configuration.

   L'identité peut être donné avec l'option --uuid, --name ou --super-minor.

   Les périphériques peuvent être donnés dans la commande --assemble ou dans le fichier de configuration. Seul les périphériques qui ont un superblock md contenant la bonne identité seront considérés.

   Le fichier de configuration est seulement utilisé s'il est explicitement donné avec --config ou requêté avec --scan. Dans ce cas, /etc/mdadm/mdadm.conf ou /etc/mdadm.conf est utilisé.

   si --scan n'est pas donné, le fichier de configuration sera seulement utilisé pour trouver l'identité d'un array

   Normallement l'array est démarré après qu'il soit assemblé. Cependant si --scan n'est pas donné et tous les disques attendu ne sont pas listés, l'array n'est pas démarré. Pour forcer l'array à être démarré dans ce cas, utiliser le flag --run

   Si udev est actif, mdadm ne créé pas d'entrée dans /dev, et laisse faire udev. Il enregistre les informations dans /run/mdadm/map qui permet à udev de choisir le nom correct. Si udev n'est pas configuré, mdadm créé lui-même les périphériques dans /dev. Dans ce cas, --auto peut être suffixé par un nombre correspondant au nombre de partitions à créer au lieu des 4 par défaut.

Auto Assemblage

   Quand --assemble est utilisé avec --scan et qu'aucun périphérique n'est listé, mdadm tente d'abord d'assembler tous les arrays listés dans le fichier de configuration. Si aucun array n'est listé dans la configuration, il recherche les périphériques disponibles à la recherche d'array et tente d'assembler ce qu'il trouve. Les array qui sont taggés comme appartenant à un homehost donné seront assemblés et démarrés normalement. Les array qui n'appartiennent pas à cet hôte sont démarrés en "read-auto" pour qui rien ne soit écrit dans ce périphérique.

   Si mdadm trouve un jeu consistant de périphériques qui semblent être dans un array, et si le superblock est taggé comme appartenant à l'hôte donné, il va automatiquement choisir un nom de périphérique et tenter d'assembler l'array. Si l'array utilise des métadonnées v0.90, le numéro mineur enregistré dans le superblock est utilisé pour créer un nom dans /dev/md/. Si l'array utilise des métadonnées v1, le nom dans le superblock est utilisé pour créer un nom dans /dev/md/.

   Ce comportement peut être modifié par la ligne AUTO dans mdadm.conf. Cette ligne peut indiquer que le type de métadonnées spécifique devrait ou non être automatiquement assemblé. Si un array est trouvé qui n'est pas listé dans mdadm.conf et a un format de métadonnées qui est refusé par la ligne AUTO, il ne sera pas assemblé. La ligne AUTO peut également exiger que tous les arrays identifiés comme appartenant à ce homehost devraient être assemblés sans regarder leur type de métadonnées.

   Note: L'auto-assemblage ne peut pas être utilisé pour assembler et activer certains array qui doivent être reshape. En particulier quand un backup-file ne peut pas être fournis, tout reshape qui nécessite un backup-file pour continuer ne peut pas être auto assemblé. Un array qui est agrandit et a passé la section critique peut être assemblée en utilisant l'auto-assemblage.

Build Mode

Similaire à --create. La différence est qu'il créé un array sans superblock. Avec ces arrays il n'y a pas de différence entre la création initiale de l'array et l'assemblage dans l'array, excepté qu'il y a des données utiles dans le second cas.

Le niveau peut être RAID0/1/10, multipath, ou faulty, ou un de leur synonymes. Tous les périphériques doivent être listés et l'array sera démarré une fois complet. Il est souvent approprié d'utiliser --assume-clean avec les raid1/10.

Create Mode

   Initialise un nouvel array md, associe certains périphériques avec lui, et active l'array. Le périphérique nommé n'existe normalement pas quand mdadm --create est lancé, mais sera créé par udev une fois l'array actif.

   Quand des périphériques sont ajoutés, ils sont vérifiés pour vois s'ils contiennent des superblocks RAID ou des systèmes de fichier. Ils sont également vérifiés pour voir si la variance dans la taille de périphérique excède 1%. Si une anomalie est constatée, l'array ne sera pas lancé automatiquement, bien que la présence de --run peut outrepasser cette précaution.

   Pour créer un array dégradé dans lequel certains périphériques sont manquants, donner simplement le mot 'missing' à la place du nom de périphérique. Cela laisse le slot correspondant vide dans l'array. Pour un raid4/5, au plus un slot peut être manquant, pour un raid6, au plus 2 slots peuvent être manquants. Pour un raid1, seul un périphérique a besoin d'être donné, tous les autres peuvent être manquant.

   En créant un array RAID5, mdadm créé automatiquement un array dégradé avec un disque spare, parce que créer le spare dans un array dégradé est généralement plus rapide que resynchroniser la parité dans un non-dégradé. Cette fonctionnalité peut être remplacée par l'option --force.

   En créant un array avec des métadonnées version 1 un nom pour l'array est requis. S'il n'est pas donné avec --name, mdadm en choisis un basé sur le dernier composant du nom du périphérique créé. Donc si /dev/md3 est créé, le nom 3 sera choisis. Si /dev/md/home est créé, home sera choisis.

   En créant une partition basée sur l'array, en utilisant mdadm avec des métadonnées v1.x, le type de partition devrait être 0xDA. Ce type permet une meilleur précision vu que l'utilisation d'autres (RAID auto-detect 0xFD, ou une partition Linux 0x83), peut créer des problèmes dans le cas de récupération d'array.

   Un nouvel array a normalement un UUID 128bits aléatoire assigné qui est unique. Il est possible de choisir l'UUID avec l'option --uuid.

   Si le type d'array support un bitmap write-intent, et si les périphériques dans l'array excèdent 100G, un bitmap write-intent interne sera automatiquement ajouté sauf si explicitement demandé avec l'option --bitmap. Dans ce pas l'espace pour un bitmap est réservé pour qu'il puisse être ajouté avec --grow --bitmat=internal.

   Si le type de métadonnées le supporte (v1.x), l'espace sera alloué pour stocker une liste de blocks défectueux.

   En créant un array avec un CONTAINER, on peut donner à mdadm soit la liste des périphériques à utiliser, ou simplement le nom du conteneur. Le premier cas permet de contrôler les périphériques à utiliser pour le raid. Le 2ème cas permet à mdadm de choisir automatiquement quels périphériques utiliser basé sur l'espace disponible.

   Les options de gestion générales qui sont valides avec --create sont:

--run Insiste pour démarrer l'array, même si des périphériques semblent être utilisés
--readonly démarre en lecture seule - pas encore supporté

Mode Manage

Permet de gérer les périphérique dans un array. Il est possible d'effectuer plusieurs opération en une commande: mdadm /dev/md0 -f /dev/hda1 -r /dev/hda1 -a /dev/hda1, qui va d'abord marque /dev/hda1 en faute, puis le supprimer de l'array, et finallement l'ajouter comme spare. Seul 1 md peut être affecter par une simple commande.

Quand un périphérique est ajouté à un array actif, mdadm vérifie pour voir s'il a des métadonnées qui spécifie s'il était récemment un membre de cet array. Si c'est le cas, it tente de ré-ajouter le périphérique. S'il n'y a pas eu de changements depuis qu'il a été supprimé, ou si l'array a un bitmap write-intent qui a été enregistré où les changements ont été faits, le périphérique devient immédiatement un membre et les différences enregistrées dans le bitmap sont résolues.

Mode Misc

Le mode MISC inclus des opérations distinct qui opérent sur des périphériques distincts. Les opération sont:

--query Le périphérique devrait être un périphérique md actif. Affiche une description détaillée de l'array. --brief et --scan réduit les détails et formatte la sortie pour être incluse dans mdadm.conf. Le code de sortie donne des informations:

0 L'array fonctionne normalement
1 L'array a au moins un disque en erreur
2 L'array a plusieurs disques en erreurs inutilisables
4 Erreur en tentant d'obtenir des informations sur le périphérique

--detail-platform Affiche des détails sur les capacités RAID de la plateforme (firmware/topologie hardware). Si les métadonnées sont spécifiées avec -e ou --metadata= le code de retour est:

0 Les métadonnées ont énuméré avec succès les composants de la plateforme dans le système
1 Les métadonnées sont indépendante de la plateforme
3 Les métadonnées ont échoué à trouver ses composants de la plateforme

--update-subarray= Si le périphérique est un conteneur et l'argument spécifie un sous-array dans le conteneur, il tente de mettre à jours le superblock dans le sous-array. C'est similaire à mettre à jours un array en mode assemble aec d'option -U.
--examine Le périphérique devrait être un composant d'un array md. mdadm lit le superblock md du périphérique et affiche le contenu. Si --brief ou --scan est donné, les périphériques qui sont des composant d'un array sont groupés ensemble et affiché comme simple entrée utilisable dans mdadm.conf.
--dump=dir Si le périphérique contient des métadonnées RAID, un fichier sera créé dans le répertoire spécifié et les métadonnées y seront écrites. Le fichier aura la même taille que le périphérique et contient les métadonnées au même emplacement. Cepenadnt le fichier sera sparse, donc seul ces blocs de métadonnées seront alloués. Plusieurs périphériques peuvent être listés.
--restore=dir Inverse de --dump. mdadm localise un fichier dans le répertoire et restore les métadonnées.
--stop Les périphériques devraient être des array md actif à désactiver, tant qu'ils ne sont pas utilisés.
--run Active un array md partiellement assemblé
--readonly Marque un array activ en lecture seule.
--scan excepté avec --examine, force l'opération à être appliqué à tous les array listés dans /proc/mdstat. --examine prend en compte les périphériques dans le fichier de configuration.
-b, --brief mode moins verbeux.

Mode Monitor

   vérifie périodiquemenent des array md et repporte tout les événements. De plus, mdadm peut déplacer les disques spare d'un array à un autre s'il est dans le même spare-group ou domain et si l'array de destinatio a un disque en erreur mais pas de spare.

   Le résultat de la supervision des array est la génération d'événements. Ces événements sont passé à un programme séparé (si spécifié) et peuvent être envoyés par mail.

   En passant les événements à un programme, celui-ci est lancé une fois par événement, et a 2 ou 3 arguments dans l'ordre: le nom de l'événement, le nom du périphérique md et le nom du périphérique.

   Si --scan est donné, un programme ou une adresse email doit être spécifié sur la ligne de commande ou dans le fichier de configuration, sinon mdadm ne supervise rien. Sans --scan, mdadm continue de superviser tant qu'il trouve quelque chose à superviser. Si aucun programme ou email n'est donné, chaque événement est reporté sur stdout. Les différents événements sont:

DeviceDisappeared Un array précédemment configuré ne semble plus être configuré (syslog priority: Critical)
RebuildStarted Un array commence la reconstruction (syslog priority: Warning)
RebuildNN où NN est un nombre indiquant le pourcentage de reconstruction effectuée. Les événements sont générés avec un incréments fixé qui peut être spécifié sur la ligne de commande. (syslog priority: Warning)
RebuildFinished Un array a été reconstruit, soit parce qu'il a fini normalement, soit parce qu'il a été annulé. (syslog priority: Warning)
Fail Un périphérique actif d'un aray a été marqué en faute (syslog priority: Critical)
FailSpare Un périphérique spare qui a été reconstruit pour remplacer un périphérique en faute a échoué (syslog priority: Critical)
SpareActive Un disque spare a été reconstruit pour remplacer un périphérique en faute et a réussi la reconstruction (syslog priority: Info)
NewArray Un nouvel array a été détecté dans le fichier /proc/mdstat (syslog priority: Info)
DegradedArray Un array apparaît être dégradé. Ce message n'est pas généré quand mdadm remarque un disque en faute qui a généré la dégradation, mais seulement quand mdadm note qu'un array est dégradé quand il est vu la première fois. (syslog priority: Critical)
MoveSpare Un disque spare a été déplacé d'un array dans un spare-group ou domain vers un autre array. (syslog priority: Info)
SparesMissing La configuration indique qu'un array devrait avoir un certain nombre de périphériques spare, mais mdadm détecte qu'il y en a moins. (syslog priority: Warning)
TestMessage Un array a été trouvé au démarrage, et le flag --test était donné (syslog priority: Info)

   Seul Fail, FailSpare, DegradedArray, SparesMissing et TestMessage sont envoyés par mail. Tous les événements sont envoyés au programme. Chaque événement a un périphériques array associé et possiblement un périphérique physique. Pour Fail, FailSpare, et SpareActive ce disque est le périphérique physique. Pour MoveSpare, ce périphérique est l'array où le spare est déplacé.

   Pour que mdadm déplace les spares d'un array à un autre, les différents arays doivent être labélisés avec le même spare-group ou les spares doivent être autorisés à migrer via les stratégies de domaine dans le fichier de configuration. les noms des spare-group doievnt être uniques.

   Quand mdadm détecte qu'un array dans un groupe de spare a moins de périphériques actifs que nécessaire pour que l'array sont complet, et n'a pas de périphériques spare, il recherche un autre array dans le même groupe de spare qui est complet et fonctionnel et possède un spare. Il va tenter de déplacer le spare, et en cas d'erreur en ajoutant le spare à l'array, il le remet dans l'array d'origine.

   Si le groupe de spare pour un array dégradé n'est pas définis, mdadm recherche les règles de migration de spare spécifié par les lignes POLICY dans mdadm.conf et effectue les même étapes ci-dessus sur les spare qui matchent.

Mode Grow

Le mode GROW est utilisé pour changer la taille ou le shape d'un array actif. Pour que cela fonctionne, le kernel doit supporter les changements nécessaire. Les changement supportés sont:

- Changer l'attribut "size" des RAID1/4/5/6.
- Augmenter ou diminuer l'attribut 'raid-devices' des RAID0/1/4/5/6
- Changer la taille de chunk et le layout des RAID0/4/5/6/10
- Convertir entre RAID1 et RAID5, entre RAID5 et RAID6, entre RAID0, RAID4 et RAID5, et entre RAID0 et RAID10.

Mode Grow

   Utiliser GROW dans les conteneurs est actuellement supporté seulement pour le format de conteneur IMSM d'Intel. Le nombre de périphériques dans un conteneur peut être augmenté, ce qui affecte tous les array dans le conteneur, ou un array dans un conteneur peut être convertis entre les niveaux supportés par le conteneur, et la conversion est un de ceux listés ci-dessus. Re-dimensionner un array dans un conteneur IMSM avec --grow --siwe n'est pas encore supporté.

   agrandir (par ex, étendre le nombre de périphériques raid) pour le format de conteneur IMSM a un status expérimental. Il est permis par la variable d'environnement MDADM_EXPERIMENTAL qui doit être à '1'. Ceci pour les raisons suivantes:

1. Le check-pointing n'a pas été pleinement testé. Cela peut causer des incompatibilités durant l'expansion: un array qui est étendus ne peut pas voyager entre Windows et les systèmes Linux.
2. Interrompre l'expansion n'est pas recommandé.

   Note: le Checkpointing natif d'Intel n'utilise pas l'option --backup-file et c'est transparent pour l'assemblage.

Changer la taile

   Normalement quand un array est construit la taille est donnée par le plus petit des disques. Si tous les petits disques dans un array sont supprimés et remplacés avec des disques plus grand, il faut changer la taille avec GROW pour prendre en compte l'espace supplémentaire. Si la taille est augmentée de cette manière, une resynchro démarre pour s'assurer que les nouvelles parties de l'array sont synchronisées.

   Noter que quand la taille d'un array change, tout système de fichier qui peut être stocké dans un array doit être explicitement étendu pour utiliser l'espace supplémentaire, ou réduit avant de réduire l'array.

   Également, la taille d'un array ne peut pas être changé s'il a un bitmap actif. Si un array a un bitmap, il doit être supprimé avant de changer la taille. Une fois le changement complet effectué, un nouveau bitmap peut être créé.

Changer les périphériques raid

   Un array RAID1 peut fonctionner avec plusieurs périphériques à partir de 1 (bien que 1 n'est pas très utile). Il est parfois souhaitable d'augmenter ou diminuer le nombre de disques actifs. Noter que c'est différents d'ajouter ou supprimer à chaud, qui change le nombre de périphériques inactifs.

   En réduisant le nombre de périphériques dans un raid1, les slots qui sont supprimés de l'array doivent déjà être vacants. C'est à dire, les périphériques qui étaient dans ces slots doivent être en erreur et supprimés.

   Changer le nombre de périphériques actifs dans un raid5/6 nécessite plus d'effort. Chaque block dans l'array doit être lu et re-écrit dans un nouvel emplacement. Le kernel est capable d'augmenter le nombre de périphériques dans un raid5 de manière sûre, incluant le redémarrage d'un reshape interrompu. Le kernel est également capable d'augmenter ou diminuer le nombre de périphériques dans un raid5 ou 6.

   Le kernel est capable de convertir un raid0 en raid4 ou 5. mdadm utilise cette fonctionnalité et la capacité d'ajouter des périphériques à un raid4 pour permettre aux périphériques d'être ajoutés dans un raid0. En demandant cela, mdadm convertis le raid0 en un raid4, ajoute les disques nécessaire et reshape, puis convertit le raid4 en raid0.

   En diminuant le nombre de disques, la taille de l'array diminue également. S'il y avait des données dans l'array, elles peuvent être supprimées de manière irréversible, donc il faut d'abord réduire le système de fichier dans l'array pour correspondre à la nouvelle taille. Pour éviter tout accident, mdadm exige que la taille de l'array soit réduite avant avec mdadm --grow --array-size. C'est un changement réversible qui rend simplement la fin de l'array inaccessible. L'integrité des données peuvent ainsi être vérifiées avant de réduire le nombre de périphériques.

   En relocalisant les tout premiers stripes dans un raid5 ou 6, il n'est pas possible de conserver les données sur le disques completement consistant et à l'épreuve des crash. Pour fournir la sécurité requise, mdadm désactive les écritures dans l'array lors du reshaping de la section critique, et créé un backup des données qui sont dans cette section. Pour les agrandissements, ce backup peut être stocké dans un des périphériques sparses de l'array, cependant il peut également être stocksé dans un fichier séparé avec --backup-file, et est obligatoire pour les réductions, changements de niveau de RAID et de layout. Si cette option est utilisée, et que le système crash durant la période critique, le même fichier doit être passé à --assemble pour restaurer le backup et réassembler l'array. En réduisant, le reshape est fait depuis la fin jusqu'au début, donc la section critique est à la fin du reshape.

Changement le level

Changer le niveau de RAID d'un array est fait instantannément. Cependant, dans le cas d'un raid5 vers un raid6 cela oblige un layout non-standard du raid6, et dans le raid6 vers un raid5 ce layout non-standard est requis avant le changement. Donc bien que le changement de niveau soit instantanné, le changement de layout peut prendre du temps. Un --backup-file est requis. Si l'array n'est pas simultannément agrandis ou réduit, la taille de l'array restera la même - par exemple, reshape un raid5 à 3 disques en un raid6 à 4 disques - le fichier backup ne sera pas utilisé seulement pour la section critique, mais via toute l'opération reshape, comme décris dans la section sur les changeents de layout.

Changement de taille de chunk et de layout

Changer la taille de chunk ou de layout sans également changer le nombre de disques implique une ré-écriture de tous les blocks. Pour éviter la perte de données en cas de crash, un --backup-file doit être fournis. Les petites section de l'array seront copiés dans le fichier backup pendant qu'ils sont réarrangés. Cela signifie que toutes les données seront copiées 2 fois, donc ce type de reshape est très lent.

Si le reshape est interrompu, ce fichier backup doit être donné à mdadm --assemble pour que l'array puisse être ré-assemblé. En conséquence, le fichie ne peut pas être stocké dans le périphériques en cours de reshape.

Changement de bitmap

Un bitmap write-intent peut être ajouté ou supprimé d'un array actif. On peut ajouter un bitmap interne ou externe. Noter que l'ajout d'un bitmap stocké dans un fichier qui est dans le système de fichier affecté dans le raid peut bloque le système.

Mode Incrémental

   Ce mode est conçu pour être utilisé en conjonction avec le système de découverte de périphérique. Quand des périphériques sont trouvés dans le système, ils peuvent être passé à mdadm --incremental pour être ajoutés à l'array approprié.

   Inversement, il peut également être utilisé avec --fail pour faire l'inverse et trouver l'array d'un périphérique particulier et le retirer.

   Si le périphérique passé est un périphériques conteneur, alors tous les arrays décris par les métadonnées du conteneur seront démarrés.

   mdadm effectue des tests pour déterminer si le périphérique fait partie d'un array, et dans quel array il devrait être membre. Si un array approprié est trouvé, ou peut être créé, mdadm ajoute le périphérique à l'array et le démarre.

   Noter que mdadm n'ajoute les périphériques à un array que s'il était fonctionnel (actif ou spare) dans l'array. Le support pour l'inclusion automatique d'un nouveau disque comme un spare dans certains array nécessite une configuration via le fichier de configuration (POLICY). Les tests que mdadm effectue sont les suivants:

- Si le périphérique est permis par mdadm.conf, c'est à dire listé dans une ligne DEVICES. Si DEVICES contient le mot clé 'partitions', tous les périphériques sont permis.
- Si le périphérique a un superblock md valide.

   mdadm conserve une liste d'array qui sont partiellement assemblés dans /run/mdadm/map. Si aucun array n'existe qui matche les métadonnées dans le nouveau périphérique, mdadm doit choisir un nom de périphérique et un numéro d'unité. Si se base sur un nom donné dans mdadm.conf et un nom stocké dans les métadonnées. Si le nom suggère un numéro d'unité, ce nombre est utilisé, sinon un numéro libre est choisis. Normalement, mdadm préfère créer un array partitionnable, cependant si la ligne CREATE dans mdadm.conf suggère un array non-partitionnable, il l'honore.

   Si l'array n'est pas trouvé dans le fichier de configuration et que ses métadonnées n'identifient pas qu'il appartient au homehost, mdadm choisis un nom pour l'array qui ne rentre pas en conflict avec un array qui appartient à cet hôte. Il le fait en ajoutant un '_' et un petit nombre au nom préférré par les métadonnées.

   Une fois un array approprié trouvé ou créé et le périphérique ajouté, mdadm doit décider si l'array est prêt à démarrer. Si compare le nombre de périphériques disponible (non-spare) au nombre de périphériques que les métadonnées suggèrent pour être actif. S'il y a assez de disque, l'array est démarré.

   --run peut alternativement être passé à mdadm auquel cas l'array sera lancé dès qu'il y a assez de disque. Notes qu'aucune de ces approche n'est vraiment idéal. Si tous les périphériques sont découverts, mdadm -IRs peut être lancé pour démarrer tous les arrays qui sont assemblés incrémentalement. Cela signifie qu'aucune mise à jours des métadonnées n'est faite, ni resyncho ou récupération. De plus, les périphériques qui sont trouvés avant la première écriture peuvent être ajoutés de manière sûre.

Variables d'environnement

MDADM_NO_MDMON Empêche de démarrage de mdmon
MDADM_NO_UDEV Ne laisse pas udev créer les fichiers de périphériques
MDADM_NO_SYSTEMCTL N'utilise pas systemd pour démarrer les tâches
IMSM_NO_PLATFORM À 1, désactive les vérifications de plateform Intel pour les raid IMSM.
MDADM_GROW_ALLOW_OLD Si un array est stoppé durant un reshape, qui utilise un fichier backup, puis il est ré-assemblé, mdadm peut se pleindre que le fichier backup est trop ancien. À 1, ne vérifie pas le fichier backup.
MDADM_CONF_AUTO Toute chaîne dans cette variable est ajoutée au démarrage de la ligne AUTO dans le fichier de configuration. Peut être utilisé pour désactiver certains types de métadonnées. (ex: '-ddf -imsm' pour désactiver ces array )

Exemples

Voir si un périphérique est un array, ou en fait partie
mdadm --query /dev/name-of-device
Assembler et démarrer tous les arrays listés dans le fichier de configuration
mdadm --assemble --scan
Stopper tous les array
mdadm --stop --scan
Si une adresse email ou un programme est donné dans le fichier de configuration, monitor le status de tous les arrays listé dan ce fichier en les requêtant toutes les 2 minutes
mdadm --follow --scan --delay=120
Créer /dev/md0 en raid1 avec /dev/hda1 et /dev/hdc1:
mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/hd[ac]1
Créer un fichier de configuration prototype qui décris les arrays actifs
echo 'DEVICE /dev/hd*[0-9] /dev/sd*[0-9]' › mdadm.conf mdadm --detail --scan ›› mdadm.conf
Trouver les array qui peuvent être assemblés depuis des disques (pas des partitions), et stocke les informations au format du fichier de configuration.
echo 'DEVICE /dev/hd[a-z] /dev/sd*[a-z]' › mdadm.conf mdadm --examine --scan --config=mdadm.conf ›› mdadm.conf
Créer une liste de périphérique en lisant /proc/partitions et assemble /dev/md0 avec tous les périphériques avec un superblock raid et un numéro mineur 0
mdadm -Ac partitions -m 0 /dev/md0
Si le fichier de configuration contient une adresse email ou un programme d'alerte, lance mdadm en fond et monitor tous les périphériques md. Écris également le fichier pid
mdadm --monitor --scan --daemonise › /run/mdadm/mon.pid
Tente d'incorporer le périphérique nouvellement découvert dans un array approprié
mdadm -Iq /dev/somedevice
Reconstruit la map d'array depuis les arrays courant, puis démarre ceux qui peuvent l'être
mdadm --incremental --rebuild-map --run --scan
Tout périphérique composant de /dev/md4 sera marqué en faute et supprimé de l'array
mdadm /dev/md4 --fail detached --remove detached
l'array /dev/md4 qui est un RAID5 sera convertis en RAID6. Il devrait normalement y avoir un disque spare dans l'array avant
mdadm --grow /dev/md4 --level=6 --backup-file=/root/backup-md4
Créer un array DDF avec 6 disques
mdadm --create /dev/md/ddf --metadata=ddf --raid-disks 6 /dev/sda /dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf
Créer un raid5 avec 3 périphériques dans le jeu DDF donné. N'utilise que 30Go dans chaque disque
mdadm --create /dev/md/home -n3 -l5 -z 30000000 /dev/md/ddf
Assemble un array ddf pré-existant
mdadm -A /dev/md/ddf1 /dev/sda /dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf
Assemble tous les arrays contenus dans l'array ddf, assignant un nom approprié
mdadm -I /dev/md/ddf1
Affiche l'aide pour le mode création
mdadm --create --help
Affiche l'aide sur le format du fichier de configuration
mdadm --config --help

Fichiers

/proc/mdstat
/etc/mdadm/mdadm.conf (ou /etc/mdadm.conf)
/etc/mdadm/mdadm.conf.d (ou /etc/mdadm.conf.d)
/run/mdadm/map

Noms des périphériques

   mdadm comprend 2 types de noms pour les périphériques array. Le premier est dit standard, qui matche les noms utilisés par le kernel et qui apparaîssent dans /proc/mdstat.

   Le second peut être librement choisi, mais doit résider dans /dev/md/. En donnant un nom à mdadm pour créer ou assembler un array, le chemin complet doit être donné, ou le suffixe du second type de nom.

   Quand mdadm choisis les noms de périphérique durant l'auto-assemblage ou l'assemblage incrémental, il ajoute parfois une petite séquence de nombre à la fin du nom pour éviter les conflits entre plusieurs array de même nom. Si mdadm peut déterminer que l'array est vraiment déstiné à cet hôte, soit par un hostname dans les métadonnées, ou par la présence de l'array dans mdadm.conf, il n'utilise pas le suffixe si possible. Également, si le homehost est spécifié en ‹ignore›, mdadm n'utilise le suffixe que si un array différent de même nom existe déja ou est listé dans la configuration.

Les noms standard sont sous la forme:
/dev/mdNN
où NN est un nombre. Les noms standard pour les arrays partitionnables sont sous la forme:
/dev/md_dNN
Les numéro de partition sont indiqués en ajoutant pMM (ex: /dev/md/d1p2)
Depuis le kernel 2.6.28 un array non-partitionnable peut être partitionné, donc md_dNN n'est plus nécessaire, et des partitions /dev/mdNNpXX sont possibles.
Depuis le kernel 2.6.29 les noms standard peut être non-numérique:
/dev/md_XXX
où XXX est une chaine. Ces noms sont supportés par mdadm v3.3.

22 mai 2016

mdadm.conf

Configuration pour mdadm

Le fichier est une collection de mots séparés par un espace. Les mot utilisant un espace sont entre guillemet simple. Une ligne commençant par un espace sont considérés comme la suite de la ligne précédente. Les mots clé sont les suivants:

DEVICE une ligne device liste les périphériques ( ou les partitions) qui peuvent contenir un composant d'un array MD. En recherchant les composants d'un array, mdadm scanne ces périphériques. Une ligne device peut contenir plusieurs périphériques séparés par des espaces et peut contenir des wirdcard, ou les mots clés containers et partitions. Ce dernier force mdadm à lire /proc/partitions et à inclure tous les périphériques et partitions trouvés. mdadm n'utilise pas les noms dans /proc/partitions mais seulement les numéros majeur et mineur. Il scanne /dev pour trouver le nom qui matche les numéros. Si aucune ligne DEVICE n'est trouvée, assume "DEVICE partitions containers".

par exemple:
DEVICE /dev/hda* /dev/hdc*
DEV /dev/sd*
DEVICE /dev/disk/by-path/pci*
DEVICE partitions

ARRAY Les lignes array identifient les arrays. le second mot peut être le nom du périphérique où l'array est normalement assemblé, tel que /dev/md1. Si le nom ne commence pas par un '/', il est traité comme relatif à /dev/md. le mot ‹ignore› peut être donné auquel cas un array qui matche le reste de la ligne n'est jamais automatiquement assemblé. Si aucun nom de périphérique n'est donné, mdadm détermine lui-même un nom approprié. les autres mots identifient l'array, ou l'array comme membre d'un groupe. Si plusieurs identités sont données, un périphérique composant doit matcher toutes les identité pour matcher. Chaque identité a un tag et une valeur. Les tags sont:

uuid= doit correspondre à l'uuid stocké dans le superblock
name= doit correspondre au nom stocké dans le superblock
super-minor= numéro mineur stocké dans le superblock
devices= Liste séparé par ',' de nom de périphérique ou motif. Seul ces périphériques seront utilisés pour assembler l'array. Ces périphériques doivent également être listés dans une ligne DEVICE
level= Niveau de RAID. Pour compatibilité avec la sortie de mdadm --examine --scan
num-devices= nombre de périphériques dans un array actif complet. Pour compatibilité avec la sortie de mdadm --examine --scan
spares= Nombre de spares attendus dans l'array.
spare-group= Nom textuel pour un groupe d'array. Tous les arrays avec le même nom de spare-group sont considérés comme étant du même groupe
auto= indique si mdadm utiliser des array partitionnable ou non, en l'absence de udev. cette option n'est plus nécessaire
bitmap= Fichier dans lequel un bitmap write-intent devrait être trouvé.
metadata= Format des métadonnées de l'array
container= spécifie que cette array est un array membre d'un conteneur. contient un chemin dans /dev ou l'uuid du conteneur
member= Spécifie que cet array est un array membre d'un conteneur. identifie quel membre d'un conteneur appartient l'array.

MAILADDR Donne une adresse email pour les alertes à envoyer quand mdadm fonctionne en mode monitor
MAILFROM Adresse de l'émetteur du mail.
PROGRAM Donne le nom d'un programme à lancer quand mdadm --monitor détecte des événements potentiellement interressant.
CREATE Donne les valeurs par défaut à utiliser en créant les arrays et les nouveaux membres d'un array. inclus:

owner=
group= id user/group ou noms à utiliser. Défaut: root/wheel ou root/disk.
mode= mode de fichier. Défaut: 0600
auto= correspond à l'opion --auto de mdadm. Donne yes, md, mdp, part, pour indiques combien de périphériques d'entrée manquant devraient être créés
metadata= Forma de métadonnées à utiliser
symlinks=no Normalement, un line dans /dev est créé par mdadm avec un nom commençant par md ou md_. Supprime la création de ce lien
names=yes Permet d'utiliser des noms arbitraires pour les périphériques md
bbl=no à no, désactive la réservation de l'espace pour la liste des blocks défectueux

HOMEHOST devrait être un nom d'hôte ou les mots clés ‹system› (utilise gethostname(2)), ‹none› (n'assume aucun nom) ou ‹ignore› (Permet de définir un nom explicit à la création)
AUTO Une liste de noms de format de métadonnées peuvent être donnés, précédé par un '+' ou un '-'. homehost est également permis équivalent à all. (0.90, 1.x, ddf, imsm).
POLICY Spécifie le comportement automatique permis sur les nouveaux périphériques dans le système et fournis une manière de marquer les spares qui peuvent être déplacer entre les array comme domaine de migration. Les domaine peuvent être définis via les policy en spécifiant un nom de domain pour des chemins dans /dev/disk/by-path. Un périphérique peut appartenir à plusieurs domaines. Le domaine d'un array est l'union des domaines de tous les périphériques dans cet array. Un spare peut être automatiquement déplacé d'un array à un autre si le domaine de l'array de destination contient tous les domaines du nouveau disque ou si les array ont le même spare-group. Les mots clés dans les policy sont:

domain= Chaine arbitraire
metadata= 0.9 1.x ddf ou imsm
path= glob de fichier correspondant à tout dans /dev/disk/by-path
type= disk ou part
auto= yes, no, ou homehost
action= include, re-add, spare, spare-same-slot, ou force-spare:

include Permet d'ajouter un disque à un array si les métadonnées dans ce disque matche cet array
re-add Inclus le périphérique dans l'array s'il apparaît en être un membre ou qu'un membre a été récemment supprimé et l'array a un bitmap write-intent pour autoriser la fonctionnalité re-add
spare Comme ci-dessus et si le périphérique est vide, il devient un spare s'il y a array qui est candidat.
spare-same-slot comme ci-dessus et si le slot a été utilisé par un array qui est dégradé et que le périphérique n'a pas de métadonnées, il devient automatiquement membre de l'array (ou son conteneur)
force-spare comme ci-dessus et le disque devient un spare dans tous les autres cas.

Exemple

DEVICE /dev/sdc1
DEVICE /dev/hda1 /dev/hdb1

ARRAY /dev/md0 UUID=3aaa0122:29827cfa:5331ad66:ca767371
ARRAY /dev/md1 superminor=1
ARRAY /dev/md2 devices=/dev/hda1,/dev/hdb1
ARRAY /dev/md4 uuid=b23f3c6d:aec43a9f:fd65db85:369432df spare-group=group1
ARRAY /dev/md5 uuid=19464854:03f71b1b:e0df2edd:246cc977 spare-group=group1
ARRAY /dev/md/home UUID=9187a482:5dde19d9:eea3cc4a:d646ab8b auto=part
ARRAY /dev/md9 name='Data Storage'

POLICY domain=domain1 metadata=imsm path=pci-0000:00:1f.2-scsi-* action=spare
POLICY domain=domain1 metadata=imsm path=pci-0000:04:00.0-scsi-[01]* action=include

MAILADDR root@mydomain.tld
PROGRAM /usr/sbin/handle-mdadm-events
CREATE group=system mode=0640 auto=part-8
HOMEHOST ‹system›
AUTO +1.x homehost -all

12 octobre 2016

multipath.conf

Fichier de configuration pour multipath

Chaque section contient un ou plusieurs attributs ou sous-sections. Les mots clé reconnus pour les attributs ou sous-sections dépendent de la section dans laquelle elles se trouvent. Les sections suivantes sont reconnues:

defaults Cette section définis les valeurs par défaut pour les attributs qui sont utilisé quand aucune valeur n'est donnée dans le périphérique approprié ou de nom de section
blacklist Définis quels périphériques devraient être exclus de la découverte de topologie multipath
blacklist_exceptions Définis quels périphérique devraient être inclus dans la découverte de topologie multipath, même s'ils sont listés dans la section blacklist
multipaths Définis les topologies multipath. Elles sont indexées par un WWID (Word Wide Identifier)
devices Définis les paramètres spécifique à un périphérique
overrides Définis les valeurs pour les attributs qui devraient remplacer les paramèters spécifique au périphérique pour tous les périphériques

Section defaults

verbosity Niveau de verbosité. (de 0 à 6, défaut: 2)
polling_interval Interval entre 2 vérifications de chemin, en seconde. Pour un fonctionnement correcte, l'interval entre les vérifications augmente graduellement jusqu'à max_polling_interval. Cette valeur sera remplacée par le paramètre WatchdogSec dans multipathd.service si systemd est utilisé. (défaut: 5).
max_polling_interval Interval maximum entre 2 vérifications de chemin, en secondes. Défaut: 4 * polling_interval
reassign_maps Active le réassignement des mappages device-mapper. Avec cette option, multipathd remap les mappages DM pour continuellement pointer vers un périphérique multiple, et non les périphériques block sous-jacent. Défaut: no
multipath_dir Répertoire où les objets partagés sont stockés. Défaut: /lib[64]/multipath/
path_selector Chemin par défaut pour l'algorithme à utiliser. Généralement offert par le kernel:

round-robin 0 Boucle tout chemin dans le groupe de chemin, envoyant la même quantité d'E/S dans chaque
queue-length 0 Envoie le prochain pool d'E/S sur le chemin ayant le moins de traitement E/S en cours
service-time 0 Choisi le chemin pour le prochain pool d'E/S basé sur sur la quantité de traitement d'E/S dans le chemin et sa bande passante relative.

path_grouping_policy Stratégie de groupement de chemin par défaut à appliquer aux multipaths non-spécifiés:

failover On chemin par groupe de priorité
multibus Tous les chemins dans un groupe de priorité
group_by_serial Un groupe de priorité par numéro de série
group_by_prio Un groupe de priorité par valeur de priorité.
group_by_node_name Un groupe de priorité par nom de nœud cible

uid_attribute Attribut udev fournissant un identifiant unique de chemin
prio Le nom de la routine de priorité de chemin. La routine spécifiée devrait retourner une valeur numérique spécifiant la priorité relative de ce chemin. Actuellement, les routines suivantes sont implémentées:

const Retourne une priorité constante de 1
sysfs Utilise les attributs sysfs access_state et preferred_path pour générer la priorité de chemin. Accepte l'option exclusive_pref_bit
emc dépendant du hardware. Génère la priorité de chemin pour les array de classe DGC
alua dépendant du hardware. Génère la priorité de chemin basé sur les paramètres SCSI-3 ALUA
ontap dépendant du hardware. Génère la priorité de chemin pour la classe RDAC LSI/Engenio/NetApp
hp_sw dépendant du hardware. Génère la priorité de chemin pour les arrays HP/COMPAQ/DEC HSG80 et MSA/HSV
hds dépendant du hardware. Génère la priorité de chemin pour les arrays Hitachi HDS Modular
random Génération aléatoire entre 1 et 10
weightedpath Génère la priorité de chemin basé sur l'expression régulière et la priorité fournie come argument nécessite prio_args

prio_args Arguments à passer à la fonction prio
features Spécifie des fonctionnalités device-mapper à utiliser. La syntaxe est num list ou num est le numéro, entre 0 et 6, des fonctionnalités dans list. Les valeurs possible pour liste sont:

queue_if_no_path Met en queue si aucun chemin n'est actif
no_partitions Désactive la génération de partitions automatique via kpartx
pg_init_retries Nombre de retentatives pg_init, doit être entre 1 et 50
pg_init_delay_msecs Nombre de secondes avant une retentative pg_init, doit être entre 0 et 60000

path_checker Méthode par défaut à utiliser pour déterminer les états de chemin. Les valeurs possibles sont:

tur Émet une commande TEST UNIT READY au périphérique
emc_clarification dépendant du hardware. requête la page spécifique EVPD 0xC0 DGC/EMC pour déterminer l'état de chemin pour les arrays CLARiiON CX/AX et EMC VNX
hp_sw dépendant du hardware. Vérifie l'état de chemin pour les arrays HP/COMPAQ/DEC HSG80 et MSA/HSV
rdac dépendant du hardware. Vérifie l'état de chemin pour la classe RDAC LSI/Engenio/NetApp
cciss_tur dépendant du hardware. Vérifie l'état de chemin pour les contrôleurs HP/COMPAQ Smart Array(CCISS)

alias_prefix Préfix user_friendly. Défaut: mpath
failback Indique comment gérer les erreurs de groupe de chemin:

immediate failback immédiatement au chemin du groupe à la priorité la plus élevée qui contient des chemins actifs.
manual N'effectue pas de failback automatique
followover N'effectue un failback automatique quand quand le premier chemin d'un pathgroup devient actif. Cela permet d'empêcher un nœud d'être rejeté quand un autre nœud demande le failover
values › 0 Défère le failback (temps en secondes)

rr_min_io Nombre d'E/S à route dans le chemin avant de basculer dans le suivant dans le même groupe de chemin. Uniquement pour le multipath basé sur BIO. Défaut: 1000
rr_min_io_rq Nombre de requêtes d'E/S à router vers un chemin avant de basculer vers le suivant dans le même groupe de chemin. Uniquement pour les requêtes basées sur multipath. Défaut: 1
max_fds Nombre maximum de descripteurs de fichier qui peuvent être ouverts par multipath et multipathd. 'max' prend la valeur dans /proc/sys/fs/nr_open. Si non définis, utilise open_fds du processus appelant. généralement 1024. Pour plus de sécurité devrait être le nombre max de chemins + 32, si ce nombre est supérieur à 1024. Défaut: max
rr_weight à priorities, le configurateur multipath assigne un poid de chemin tel que "path prio * rr_min_io". peut être priorities ou uniform
no_path_retry Spécifie le nombre de retentatives jusqu'à désactiver la queue, ou fail pour échouer immédiatement. queue ne stop jamais la queue. Si non définis, aucune queue n'est tentée
queue_without_daemon à no, quand multipathd stoppe, la queue est désactivée pour tous les périphériques. Utile pour les périphériques qui définissent no_path_retry. Si une machine s'éteint alors que tous les chemins sont down, il est possible de bloquer en attende d'E/S du périphérique après que multipathd ai été stoppé. Sans multipathd, l'accès aux chemins ne peut être restauré, et le kernel ne peut pas indiquer de stopper la queue. Défaut: no
checker_timeout Spécifie le timeout à utiliser pour la vérification de chemin et es prioritiseurs qui émettent des commandes SCSI avec un timeout explicit. Défaut: /sys/block/sd‹x›/device/timeout
flush_on_last_del À yes, multipathd désactive la queue quand le dernier chemin vers un périphérique a été supprimé. Défaut: no
user_friendly_names À yes, en utilisant le fichier /etc/multipath/bindings pour assigner de manière persistante et unique un alias au multipath, sous la forme mpath‹n›. À no, utilise le wwid comme alias.
fast_io_fail_tmo Nombre de secondes d'attente de la couche SCSI après qu'un problème ait été détecté sur un port distant FO avant d'échouer les E/S sur ce port. Devrait être inférieur à dev_loss_tmo. Défaut: 5
dev_loss_tmo Nombre de secondes d'attente de la couche SCSI après qu'un problème ait été détecté sur un port distant FO avant de le supprimer du système. 'infinity' définis à la valeur max (2147483647 secondes, ou 68ans). Il sera automatiquement ajusté à l'interval no_path_retry addentry articles autoadd autofind autoprod createalpha createbeta createdb createprod findentry fullpowa generator.php genhtml genman genmd gentex html insert man md pdf regen setfor setfor2 sql temp temp-new-pc tex threads ToDo polling_interval si un nombre de tentatives est donné dans no_path_retry et que l'interval de retentative qlobal est supérieur à dev_loss_tmo. Linux définis cette valeur à 300 si fast_io_fail_tmo n'est pas définis. Défaut: 600
bindings_file Chemin complet du fichier binding à utiliser quand l'option user_friendly_names est définis.
wwids_file Chemin complet du fichier eds WWID, utilisé pour garder une trace des WWID pour les LUN qui ont été créés dans le passé
log_checker_err À 'once', multipathd log la première erreur de vérification de chemin au niveau 2, et les autres erreur au niveau 3 jusqu'à ce que le périphérique soit restauré. À 'always', multipathd logs toujours au niveau 2
reservation_key Clé de réservation d'action du service utilisé par mpathpersist. Il doit être définis pour tous les périphériques multipath utilisant les réservation persistantes, et doit être identique au champ RESERVATION KEY du paramètre PERSISTENT RESERVE OUT.
retain_attached_hw_handler À yes, si la couche SCSI a déjà attaché un hardware_handler au périphérique multipath, multipath ne force pas le périphérique à utiliser celui spécifié dans ce fichier de configuration. Défaut: yes
detect_prio À yes, multipath tente de détecter si le périphérique supporte SCSI-3 ALUA. Si c'est le cas, le périphérique utilisera automatiquement le prioritizer sysfs si les attributs access_state et preferred_path sont supportés, ou le prioritiseur alua le cas échéant.
force_sync À yes, multipathd Vérifie les chemin en mode sync uniquement. Cela signifie que seul un vérificateur tourne à la fois, utile quand les vérificateurs tournant en parallèle créent une surchage CPU.
strict_timinig À yes, multipathd démarre une nouvelle boucle de vérification de chemin après exactement 1 seconde, pour que chaque vérification de chemin se produise exactement à polling_interval secondes. Si les systèmes surchargés, les vérification peuvent prendre plus d'une seconde
deferred_remove À yes, multipathd déferre la suppresion au lieu d'une suppression régulière quand le dernier chemin a été supprimé. Cela signifie que si le périphérique continue à être utilisé, il sera libéré quand le dernier utilisateur le fermera.
partition_delimiter Non définis, quand multipath renomme un périphérique, il agit simplement comme kpartx. ajoute seulement un 'p' aux noms se terminant dans un nombre. Si définis, multipath agit comme "kpartix -p" et ajoute toujours un délimiteur
config_dir Si définis, multipath recherche dans ce répertoire pour des fichiers .conf, et y lit les informations de configuration, tout comme /etc/multipath.conf.
delay_watch_checks › 0, multipathd recherche les chemins qui sont devenus récemment valides durant ce délai.
delay_wait_checks › 0, quand un périphérique qui est récemment revenu online échoue de nouveau dans le délai delay_watch_checks, la prochaine fois qu'il revient online il sera marqué et retardé, et ne sera pas utilisé jusqu'à ce qu'il ait passé ces vérification
find_multipaths À yes, au lieu de tenter de créer un périphérique multipath pour chaque chemin non-blacklisté, multipath créé seulement un périphérique si une des 3 conditions sont rencontrées: 1) il y a au moins 2 chemins non-blacklistés avec le même WWID, 2) l'utilisateur force manuellement la création en spécifinat un périphérique avec la commande multipath, ou 3) un chemin a le même wwid précédemment créé. Défaut: no
uxsock_timeout timeout CLI reçu en ms. Défaut: 1000
retrigger_tries Nombre de fois que multipathd tente de gérer un uevent pour obtenir le WWID. Défaut: 3
retrigger_delay Définis le délai, en secondes, d'attente entre les triggers. Défaut: 10
missing_uev_wait_timeout Contrôle le délai d'attente de multipathd après qu'un nouveau périphérique multipath soit créé, pour reçevoir un évènement de changement de udev pour ce périphérique, avant d'activer automatiquement les reloads de périphérique. Défaut: 30

Section blacklist

devnode expression régulière des périphériques à exclure
wwid Le wwid d'un périphérique
property Expression régulière d'une propriété udev à exclure
device Sous-section pour la description d'un périphérique. Accepte les mots-clé vendor et product

Section blacklist

devnode expression régulière des périphériques à inclure
wwid Le wwid d'un périphérique
property Expression régulière d'une propriété udev à inclure
device Sous-section pour la description d'un périphérique. Accepte les mots-clé vendor et product

Section multipaths

multipath Sous-section décrivant un multipath

wwid Index du conteneur
alias nom symbolique pour le mappage multipath
path_grouping_policy
path_selector
prio
prio_args
failback
rr_weight
no_path_retry
rr_min_io
rr_min_io_rq
flush_on_last_del
features
reservation_key
user_friendly_names
deferred_remove
delay_watch_checks
delay_wait_checks Identiques à la section defaults

Section devices

device Sous-section décrivant un périphérique

vendor Identifiant de vendeur
product Identifiant de produit
revision Identifiant de révision
product_blacklist Chaîne à blacklister pour ce vendeur
alias_prefix Préfix user_friendly à utiliser pour ce type de périphérique
hardware_handler hardware handler à utiliser pour ce type de périphérique:

emc DGC class arrays as CLARiiON CX/AX and EMC VNX
rdac LSI/Engenio/NetApp RDAC class
hp_sw HP/COMPAQ/DEC HSG80 and MSA/HSV arrays
alua SCSI-3 ALUA compatible arrays

path_grouping_policy
uid_attribute
path_selector
path_checker
prio
prio_args
features
failback
rr_weight
no_path_retry
rr_min_io
rr_min_io_rq
fast_io_fail_tmo
dev_loss_tmo
flush_on_last_del
retain_attached_hw_handler
detect_prio
deferred_remove
delay_watch_checks
delay_wait_checks Options identiques à la section defaults

Section overrides

path_grouping_policy
uid_attribute
getuid_callout
path_selector
path_checker
alias_prefix
features
prio
prio_args
failback
rr_weight
no_path_retry
rr_min_io
rr_min_io_rq
flush_on_last_del
fast_io_fail_tmo
dev_loss_tmo
user_friendly_names
retain_attached_hw_handler
detect_prio
deferred_remove
delay_watch_checks
delay_wait_checks Options identiques à la section devices ou defaults

collie

OPTIONS

Commandes et sous-commandes

gluster

Commandes

Commandes de briques

Commandes des logs

Commandes de paires

Commandes tier

Commandes Geo-replication

Commandes bitrot

commandes de snapshots

Commande heal

Autres commandes

glusterd

OPTIONS

glusterfs

OPTIONS

Options fuse

Exemples

kpartx

OPTIONS

Exemples

md

Métadonnées MD

Métadonnées sans arrays

Métadonnées externes

LINEAR

RAID0

RAID1

RAID4

RAID5

RAID6

RAID10

Exemples de layout raid10

Arrêt non propre

Récupération

scrubbing et mismatches

Bitmap write-intent logging

Bad block list

Journal d'écriture RAID456

write-behind

RESTRIPING

Interface sysfs

Paramètres kernel

Fichiers

mdadm

Modes

Options pour sélectionner un mode

Options non spécifique au mode

Options pour create, build, ou grow

Options pour l'assemblage

Pour le mode Manage

Mode Misc

Mode assemblage incrémental

Mode Monitor

Mode ASSEMBLE

Auto Assemblage

Build Mode

Create Mode

Mode Manage

Mode Misc

Mode Monitor

Mode Grow

Mode Grow

Changer la taile

Changer les périphériques raid

Changement le level

Changement de taille de chunk et de layout

Changement de bitmap

Mode Incrémental

Variables d'environnement

Exemples

Fichiers

Noms des périphériques

mdadm.conf

Exemple

mdmon

Mises à jours des métadonnées

Conteneurs