Apparence
Uubu.fr

Les systèmes Linux, l’open source, les réseaux, l’interopérabilité, etc.
« Il vaut mieux viser la perfection et la manquer que viser l’imperfection et l’atteindre. » (Bertrand Arthur William RUSSEL)
12 octobre 2016

htmlpdflatexmanmd




kpartx

kpartx

Créer des maps de périphérique depuis des tables de partition

   Cet outil, dérivé de partx, lit les tables de partitions sur le périphérique spécifié et créé des maps de périphérique sur les segments de partition détectés.

OPTIONS

-a Ajoute des mappages de partition
-r Mappages lecture seule
-d Supprimer des mappages de partition
-u Mettre à jours des mappages de partition
-l Liste les mappages de partition qui aurait été ajouté avec -a
-p Définis le délimiteur de numéro de partition
-f Force la création des mappages
-g Force la table de partition GUID
-v mode verbeux
-s Mode syncho. Ne retourne pas tant que les partitions ne sont pas créées

Exemples

Monter toutes les partitions dans une image raw
kpartx -av disk.img
cela affichera:
loop3p1 : 0 20964762 /dev/loop3 63
Pour vérifier la partition:
fsck /dev/mapper/loop3p1
Pour supprimer le périphérique
kpartx -d disk.img
^
22 mai 2016

htmlpdflatexmanmd




md

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

htmlpdflatexmanmd




mdadm

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
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
XXX est une chaine. Ces noms sont supportés par mdadm v3.3.
^
22 mai 2016

htmlpdflatexmanmd




mdadm.conf

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
^
22 mai 2016

htmlpdflatexmanmd




mdmon

mdmon

Supervision des métadonnées md externes

   le kernel 2.6.27 ajoute le support des métadonnées externes. Ces métadonnées externes impliques que l'espace utilisateur gère toutes les mises à jours des métadonnées. La responsabilité du kernel est de notifier l'espace utilisateur quand un événement de métadonnées se produit, tels qu'une erreur disque. Le kernel, dans des cas importants, attends l'espace utilisateur pour prendre une action sur ces notifications.

Mises à jours des métadonnées

   mdmon est un service de mise à jours des métadonnées. mdmon requête l'espace de nom sysfs à la recherche de changements dans les attributs array_state, sync_action et state. Quand un changement est détecté il appel un handler par type de métadonnées pour effectuer les modifications sur les métadonnées. Les actions sont les suivantes:

array_state - inactif Efface le bit dirty pour le volume et laisse l'array stoppé
array_state - write pending Définis le bit dirty pour l'array puis met array_state à actif. Les écritures sont bloquées tant que les écritures de l'espace utilisateur sont actifs
array_state - active-idle Le timer safe mode a expiré pour l'array et définis l'état pour nettoyer les écritures de block dans l'array
array_state - clean Efface le bit dirty pour le volume
array_state - read-only État initial de tous les array au démarrage. mdmon prend une des 3 actions suivantes:

        1/ Transition de l'array vers read-auto conservant le bit dirty effacé si le handler de métadonnées détermine que l'array n'a pas besoin de resynchro ou autre modifications
        2/ Transition de l'array vers actif si le handler de métadonnées détermines qu'une resynchro ou autres manipulations est nécessaire.
        3/ Laisser l'array read-only si le volume est marqué à ne pas superviser.

sync_action - resync-to-idle Notify l'handler de métadonnées qu'une resynchro peut avoir fini. Si un processus de resynchro est en attente avant d'être complété, cet événement permet au handler de métadonnées de vérifier la resynchro
sync_action - recover-to-idle Un spare peut avoir finis la reconstruction donc indique au handler l'état de chaque disque. C'est l'opportunité de l'handler d'effacer les bits out-of-sync et le status dégradé du volume.
‹disk›/state - faulty Une erreur disque déclenche une série d'événements. D'abord, notify le handler qu'un disque a échoué, et notify le kernel qu'il peut débloquer les écritures qui étaient dépendant de ce disque. Ensuite le disque est mis à removed+ de l'array membre. Finallement le disque est marqué en erreur dans tous les autres array membre dans le conteneur.

Conteneurs

   Les formats de métadonnées externe, comme DDF, diffèrent des formats de métadonnées MD natifs dans le sens qu'ils définissent un jeu de disques et une série de sous-array dans ces disques. Les métadonnées en comparaison définissent une relation 1:1 entre un jeu de périphériques block et un array RAID. Par exemple, pour créer 2 array à différents niveaux RAID dans un simple jeu de disques, les métadonnées MD nécessitent que les disques soient partitionnés puis chaque array peut être créé avec un sous-jeu de ces partitions. Les formats externes supportés effectuent cet opération disques en interne.

   Les périphériques conteneur maintiennent simplement les références de tous les disques membre et permet aux outils mdmon de déterminer quels array actifs appartiennent à quel conteneur. Certaines commandes de gestion d'array comme la suppression ou l'ajout de disque sont seulement valides au niveau du conteneur. Les conteneurs sont identifiés dans /proc/mdstat avec une vversion de métadonnées "external:‹metadata name›". Les périphériques membres sont identifiés par "external:/‹container device›/‹member index›", ou "external:-‹container device›/‹member index›" si l'array est lecture seule.

Options

CONTAINER Le périphérique conteneur à superviser. Peut être un chemin complet comme /dev/md/container, ou un simple nom de périphérique md.
--foreground Ne lance pas en tâche de fond
--takeover Instruit mdmon de remplacer un service mdadm déjà en cours d'exécution
--all Trouve tous les conteneurs actifs et démarre le monitoring sur chacun d'entre-eux

Démarrage et arrêt

   mdmon doit être lancé quand un système de fichier dans le périphérique monitoré est monté avec des considérations spéciale quand le système de fichier root est monté depuis un périphérique mdmon supervisé. Noter qu'en général mdmon est nécessaire même si le système de fichier est monté en lecture seule. et certains systèmes de fichier restent en écriture dans ces circonstances, par exemple pour rejouer un journal après un arrêt non propre.

   Quand l'array est assemblé par le code initramfs, mdadm démarre automatiquement mdmon si requis. Cela signifie que mdmon doit être installé dans l'initramfs et doit il doit y avoir un système de fichier en écriture dans lequel mdmon peut créer un pid et un socket. Le système de fichier particulier à utiliser est donné à mdmon à la compilation. défaut: /run/mdadm.

   Une fois le système root instancié avec un pivot_root, mdmon devrait être lancé avec --all --takeover pour que le mdmon lancé dans l'initramfs puisse être remplacé.

   À l'arrêt, mdmon ne devrait pas être terminer avec les autres processus. Vu qu'il maintien un fichier ouvert dans /dev, il n'est pas possible de démonter /dev si c'est un système de fichie séparé

Exemples

Terminer le mdmon en cours d'exécution est terminé et une nouvelle instance est démarré:
mdmon --all-active-arrays --takeover
^
12 octobre 2016

htmlpdflatexmanmd




multipath

multipath

Auto-configuration de targets Device Mapper

   multipath est utilisé pour détecter et regrouper les chemins multiples vers des périphériques, pour la tolérance aux pannes ou pour des raisons de performance.

OPTIONS

-v level Niveau de verbosité

        0 Pas de sortie
        1 Affiche les noms créés ou mis à jours uniquement
        2+ Affiche toutes les informations

-d mode simulation
-l Affiche la topologie multipath depuis les informations dans sysfs et device mapper
-ll Affiche la topologie multipath depuis tous les sources d'information disponible
-f Enlève le périphérique multipath spécifié, si inutilisé
-F enlève tous les périphériques multipath non-utilisés
-t Affiche la table hardware interne
-r Force le rechargement devmap
-i Ignore le fichier wwids en traitant les périphériques
-B Traite le fichier bindings en lecture seule
-b bindings_file Spécifie l'emplacement du fichier bindings
-c Vérifie si un périphérique block devrait être un chemin dans un périphérique multipath
-q Autorise les tables de périphérique avec queue_if_no_path quand multipathd n'est pas en cour de fonctionnement
-a Ajoute le wwid pour le périphérique spécifié dans le fichiers wwids
-u Vérifie si le périphérique spécifié dans l'environnement devrait être dans un périphérique multipath
-w Supprime le wwid pour le périphérique spécifié dans le fichier wwid
-W Réinitialise le fichier wwid pour seulement inclure les périphériques multipath courants
-p policy Force les nouveaux mappage à utiliser la stratégie spécifiée:

        failover 1 chemin par groupe de priorité
        multibus Tous les chemins dans un groupe de priorité
        group_by_serial Un groupe de priorité par sérial
        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. Les noms sont pris dans /sys/class/fc_transport/target*/node_name
^
12 octobre 2016

htmlpdflatexmanmd




multipath.conf

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
^
12 octobre 2016

htmlpdflatexmanmd




multipathd

multipathd

service multipath

   Le service multipathd est en charge de vérifier les chemins en erreur. Quand celà se produit, il reconfigure la map multipath auquel le chemin appartient, pour que cette map regagne un maximum de performance et de redondance.

   Ce service exécute l'outil de configuration multipath externe quand les événements se produisent. En retour, l'outil multipath signale au service multipathd quand c'est fait avec la reconfiguration devmap, pour qu'il puisse rafraîchir sa liste de path échoués.

OPTIONS

-d Ne met pas en tâche de fond.
-s Supprime l'horodatage
-v level Niveau de verbosité. 0=error. 3 et + affiche beaucoups d'information
-B Liaisons lecture-seule
-k Mode interractif.
-n  Ignore les nouveaux périphériques

Commandes

list|show paths Affiche les chemins que multipathd monitore et leur état.
list|show paths format $format Affiche les chemins que multipathd monitore en utilisant un format spécifié
list|show maps|multipaths Affiche les périphériques multipath que multipathd monitore
list|show maps|multipaths format $format Affiche le status de tous les périphériques multipath qui multipathd gère, en utilisant un format contenant des wildcard
list|show maps|multipaths status Affiche le status de tous les périphériques que multipathd monitore
list|show maps|multipaths stats Affiche des statistiques sur tous les périphériques multipath que multipathd monitore
list|show maps|multipaths topology Affiche la topologie multipath courante. Identique à multipath -ll
list|show topology Affiche la topologie multipath courante. Identique à multipath -ll
list|show map|multipath $map topology Affiche la topologie d'un périphérique multipath spécifié par $map.
list|show wildcards Affiche le format wildcard utilisé dans les commandes interactives
list|show config Affiche la configuration actuelle
List|show blacklist Affiche les règles blacklist courantes
list|show devices Affiche tous les périphériques block par nom et s'il sont blacklistés ou non
list|show status Affiche le nombre de vérificateurs de chemin dans chaque état possible, le nombre de chemins monitorés, et si multipathd gère actuellement un uevent
list|show daemon Affiche l'état du service multipathd
add path $path Ajoute un chemin à la liste des chemins monitorés. $path est tel que listé dans /sys/block
remove|del path $path Arrête de monitorer un chemin
add map|multipath $map Ajoute un périphérique multipath à la liste des périphériques monitorés. $map peut être un périphérique dm tel que listé dans /sys/block, un alias, ou un uid.
remove|del map|multipath $map Arrête de monitorer un périphérique multipath
resize map|multipath $map Redimensionne $map à la taille donnée
switch|switchgroup map|multipath $map group $group Force un périphérique multipath à passer dans un groupe de chemin spécifique. $group est l'index du groupe de chemin, en commençant à 1
reconfigure Reconfigure les multipaths
suspend map|multipath $map Met la $map en pause
resume map|multipath $map Relance une $map en pause
reset map|multipath $map Réassigne des tables dm existants en utilisant le périphérique multipath au lieu de ses chemins
reload map|multipath $map Recharge un périphérique multipath
fail path $path Met le chemin $path à l'état échoué
reinstate path $path Réactive un $path à l'état échoué
disablequeueing maps|multipaths Désactive la queue dans tous les périphériques multipath
restorequeueing maps|multipaths Réactive la queue dans tous les périphériques multipath
disablequeueing map|multipath $map Désactive la queue sur le $map
restorequeueing map|multipath $map Réactive la queue dans le $map
forcequeueing daemon Force multipathd en mode queue_without_daemon pour que la queue no_path_rethy ne se désactive pas quand le service s'arrête
restorequeueing daemon Restaure le mode queue_without_daemon configuré
map|multipath $map setprstatus Active la gestion de réservation persistante sur $map
map|multipath $map unsetprstatus Désactive la gestion de réservaion persistante sur $map
map|multipath $map getprstatus Affiche le status de la gestion de réservation persistante sur $map
quit|exit Quitter la session interactive
shutdown Stop multipathd

Intégration système

   Compilé avec le support systemd, 2 fichiers de service systemd sont installés, multipathd.service et multipathd.socket. Ce dernier instruit systemd d'intercepter le socket de commande CLI, pour que tout appel à l'interface CLI démarre le service si nécessaire. multipathd.service gère les définitions pour contrôler le service. Le service lui-même utilise l'interface sd_notify(3) pour communiquer avec systemd. Les mots clé suivant sont reconnus:

WatchdogSec= Active le watchdogSec interne à systemd. multipath envoie des notifications via sd_notify(3) à systemd pour réinitialiser le watchdog. les paramètres polling_interval et max_polling_interval sont remplacés par les paramètres watchdog.
OOMScoreAdjust= Remplace le mécanisme d'ajustement OOM interne
LimitNOFILE= Remplace le paramètre max_fds
^
25 avril 2017

htmlpdflatexmanmd




cache_check

cache_check

réparer les métadonnées cache

OPTIONS

-q, --quiet mode silencieux
--super-block-only Ne vérifie que la présence du superbloc
--skip-mappings ne vérifie pas le mappage de block qui constitue la majeur partie des métadonnées
--skip-hints Ne vérifie pas les valeurs de stratégie des métadonnées
--skip-discards Ne vérifie pas les bits discard dans les métadonnées
^
25 avril 2017

htmlpdflatexmanmd




cache_dump

cache_dump

dump les métadonnées cache du périphérique sur stdout

OPTIONS

-r, --repair Répare les métadonnée durant le dump
^
25 avril 2017

htmlpdflatexmanmd




cache_repair

cache_repair

Répare les métadonnées cache

OPTIONS

-i, --input {device|file} Fichier ou périphérique d'entrée
-o, --output {device|file} fichier ou périphérique de sortie. Si un fichier est utilisé, il doit être préalloué et suffisamment grand pour maintenir les métadonnées
^
25 avril 2017

htmlpdflatexmanmd




cache_restore

cache_restore

restaure le fichier de métadonnées de cache

OPTIONS

-i, --input {device|file} Fichier ou périphérique d'entrée
-o, --output {device|file} fichier ou périphérique de sortie. Si un fichier est utilisé, il doit être préalloué et suffisamment grand pour maintenir les métadonnées
{--debug-override-metadata-version} ‹integer› spécifie la version des métadonnées. pour débuggage.
^
06 juin 2016

htmlpdflatexmanmd




clvmd

clvmd

Service de cluster LVM

   clvmd est le service qui distribut les mises à jours de métadonnées LVM dans le cluster. Il doit être lancé sur tous les nœuds dans le cluster et affiche une erreur si un nœud du cluster n'a pas ce service.

OPTIONS

-C Seulement valide avec -d. Indique à tous les clvmd dans le cluster d'activer/désactiver le débug. Sans cette option, seule le service local est concerné.
-d [value] Définis le niveau de log de débuggage (0, désactivé, 1 envoie sur stderr, 2 envoie à syslog)
lock_uuid uuid de lock à ré-acquérir exclusivement quand clvmd est redémarré
-F Ne lance pas en tâche de fond
-I cluster_manager Sélectionne le gestionnaire de cluster à utiliser pour les locks et les communications internes. Il est possible d'avoir plusieurs gestionnaires disponible, cette option permet d'empêcher la recherche. Par défaut, auto utiliser le premier gestionnaire qui réussit, et les vérifie dans un ordre prédéfinis cman, corosync, openais. Les gestionnaires disponibles seront listés dans l'ordre via clvmd -h.
-R Indique à toutes les instance de clvmd dans le cluster de recharger leur cache de périphérique et re-lire la configuration lvm.
-S Indique à clvmd de quitter et se ré-exécuter.
-t timeout timeout pour les commandes à lancer dans le cluster. (défaut: 60 secondes)
-T start_timeout timeout de démarrage du service. Défaut: 0 (pas de délai). ignoré avec -d

Variables d'environnements

LVM_CLVMD_BINARY emplacement du binaire clvmd. Défaut: /usr/sbin/clvmd
LVM_BINARY binaire lvm2 à utiliser. Défaut: /sbin/lvm
^
16 juin 2016

htmlpdflatexmanmd




cmirrord

cmirrord

Service de log des mirroirs en cluster

   cmirrord est le service qui surveille les informations de log mirroir dans un cluster. C'est spécifique aux mirroirs basés sur DM.

   Ce service s'assure que l'infrastructure cluster fournie par le gestionnaire de cluster (CMAN), qui doit être fonctionnel pour que cmirrord puisse fonctionner. La sortie est loggée via syslog.

OPTIONS

-f, --foreground Ne lance pas en tâche de fond, log sur le terminal
^
16 juin 2016

htmlpdflatexmanmd




dmeventd

dmeventd

Service d'événements Device-mapper

   dmeventd est le service de supervision d'événements pour les périphériques dm. Les librairies peuvent s'enregistrer et gérer les actions quand des événements particuliers se produisent.

LVM plugins

Mirror Tente le gérer les erreurs disque automatiquement
Raid Tente le gérer les erreurs disque automatiquement
Snapshot Supervise la taille d'un snapshot et émet une alerte à syslog quand il excède 80%, répété à 85%, 90% et 95%.
Thin Supervise la taille d'un pool thin et émet une alerte à syslog quand il excède 80%, répété à 85%, 90% et 95%.

OPTIONS

-d, -dd, -ddd Augmente les détailles des messages de debuggage envoyés à syslog.
-F Ne lance pas en tâche de fond
-l Uniquement avec -f. Log sur stdout et stderr au lieu de syslog.
-R Remplace une instance dmeventd en cours de fonctionnement
^
25 avril 2017

htmlpdflatexmanmd




dmevent_tool

dmevent_tool

Utilitaire pour (dé)enregistrer les DSO avec dmeventd

OPTIONS

-m[r|u] Liste tous les périphériques dm actifs enregistrés (r), ou désenregistrés (u)
-a[r|u] Idem pour pour des périphériques avec UUID uniquement.
-r Enregistre un périphérique avec dmeventd
-u Désenregistre un périphérique avec dmeventd
^
23 mai 2016

htmlpdflatexmanmd




fsadm

fsadm

Utilitaire pour redimensionner ou vérifier le système de fichier dans un périphérique. Il tente d'utiliser la même API pour ext2/3/4, ReiserFS et XFS

OPTIONS

-e, --ext-offline Démonte les systèmes de fichier ext2/3/4 avant de redimensionner
-f, --force bypasse certaines vérifications
-n, --dry-run Affiche les commandes sans les lancer
-v, --verbose mode verbeux
-y, --yes Répond yes a toutes les questions
new_size[B|K|M|G|T|P|E] Nombre absolue de blocks de système de fichier dans le système de fichier, ou une taille absolue utilisant un suffix en puissance de 1024.

Diagnostiques

   Une fois complété avec succès, le code de status est 0. 2 indique que l'opération a été intérrompue par l'utilisateur. 3 indique que l'opération de vérification en peut pas être effectuée parce que le système de fichier est monté et ne supporte pas un fsck online. 1 indique une autre erreur.

Variables d'environnement

TMPDIR Répertoire temporaire pour les points de montage (défaut. /tmp)
DM_DEV_DIR Nom du répertoire de périphériques. Défaut: /dev.
^
15 juin 2016

htmlpdflatexmanmd




lvchange

lvchange

Changer les attributs d'un volume logique

OPTIONS

-a|--activate [a][e|s|l]{y|n} Contrôle la disponibilité des volumes logiques à utiliser immédiatement après que la commande soit terminées. Par défaut, les nouveaux volumes logiques sont activés (-ay). -an laisse le nouveau volume logique inactif si possible. -aay, l'autoactivation est gérée avec un match dans activation/auto_activation_volume_list dans lvm.conf. -aey active exclusivement sur un nœud et -a{a|l}y active seulement sur le nœud local.
--activationmode {complete|degraded|partial} Le mode d'activation détermine si les volumes logiques sont autorisés à être activés quand il y a des volumes physiques manquant. complete est le plus restrictif. degraded autorise les LV RAID même si des PV sont manquant (mirror n'est pas considéré comme LV raid). partial permet d'activer tout LV même si des portions sont manquants
--addtag Tag Ajoute le tag spécifié. Peut être spécifié plusieurs fois
-K|--ignoreactivationskip Ignore le flag skip des LV durant l'activation.
-k|--setactivationskip {y|n} Contrôle si les volumes logiques sont flaggés pour être ignoré à l'activation. --ignoreactivationskip doit être utilisé. Le flag n'est pas appliqué durant la désactivation. Utiliser lvchange --setactivationskil pour changer le flag skip. voir activation/auto_set_activation_skip dans lvm.conf.
--alloc AllocationPolicy Sélectionne la stratégie d'allocation (anywhere|contiguous|cling|inherit|normal)
-A|--autobackup {y|n} Backup automatiquement les métadonnées après un changement
--cachepolicy Policy Seulement pour les LV cache. Définis la stratégie de cache. mq est la stratégie de base, smq est plus avancé
--cachesettings Key=Value Seulement pour les LV cache. Définis les paramètres cache.
--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-C|--contiguous {y|n}
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
--deltag Tag
--detachprofile
--discards {ignore|nopassdown|passdown}
--errorwhenfull {y|n}
--ignorelockingfailure
--ignoremonitoring Ne tente pas d'interragir avec dmeventd sauf si --monitor est spécifié
--ignoreskippedcluster
--metadataprofile ProfileName Sélectionne le profile de configuration des métadonnées à utiliser
--monitor {y|n} Active le monitoring d'un mirroir, snapshot ou pool thin avec dmeventd si installé. Si un périphérique utilisé par un mirroir monitoré reporte une erreur d'E/S, l'erreur est gérée en accord avec activation/mirror_image_fault_policy et activation/mirror_log_fault_policy dans lvm.conf
--noudevsync Désactive la synchronisation udev. Le processus n'attend pas de notification udev.
-P|--partial
-p|--permission {r|rw} Définis les permissions d'accès. Défaut: rw
-M|--persistent {y|n} [--major Major] [--minor Minor] À yes, le numéro mineur est persistant. Les volumes pool ne peuvent pas avoir de numéros mineur et majeur persistants. Définis le numéro majeur et mineur. Non supporté avec les volumes pools. Ignoré avec les kernels récents
--poll {y|n} Sans le polling de transformation en tâche de fond d'un volume logique le processus ne se complète jamais. S'il y a un pvmove ou lvconvert incomplet, utiliser --poll y pour relancer le processus.
--[raid]maxrecoveryrate Rate Définis le taux de récupération maximum pour un volume RAID. Le taux est spécifié comme quantité par seconde pour chaque périphérique dans l'array.
--[raid]minrecoveryrate Rate éfinis le taux de récupération minimum pour un volume RAID. Le taux est spécifié comme quantité par seconde pour chaque périphérique dans l'array.
--[raid]syncaction {check|repair} Utilisé pour initialiser diverses opérations de synchronisation RAID. check et repair fournissent un moyen de vérifier l'intégrité du lv RAID.
--[raid]writebehind IOCount Nombre maximum d'écritures en suspend permis dans les périphériques dans un RAID1 marqué write-mostly. Une fois cette valeur atteinte, les écritures deviennent synchrones. À 0, permet au système de choisir la valeur arbitrairement.
--[raid]writemostly PhysicalVolume[:{y|n|t}] Marque un périphérique RAID1 en write-mostly. Toutes les lectures sur des périphériques sont évités sauf si nécessaire.
-r|--readahead {ReadAheadSectors|auto|none} Définis le compteur de secteur read ahead de ce volume logique.
--refresh Si le lv est actif, recharche ses métadonnées.
--resync Force une resynchronisation complète d'un mirroir.
-S|--select Selection Critère de sélection
--sysinit Indique que lvchange est invoqué à l'initialisation du système, avant que les systèmes de fichiers accessible en écriture soient disponibles. Équivalent à --ignorelockingfailure --ignoremonitoring --poll n et définir LVM_SUPPRESS_LOCKING_FAILURE_MESSAGES
-t|--test Lance en mode test
-v|--verbose Mode verbeux
-Z|--zero {y|n} Définis le mode de provisionnement pour les pool thin.

Variables d'environnement

LVM_SUPPRESS_LOCKING_FAILURE_MESSAGES Supprime les messages d'erreur de lock

Exemples

Change les permissions dans le volume lvol1 dans le vg vg00
lvchange -pr vg00/lvol1
^
06 juin 2016

htmlpdflatexmanmd




lvconvert

lvconvert

Convertis un volume logique lineaire vers un mirroir ou snapshot

   lvconvert est utilisé pour changer le type de segment ou les caractéristiques d'un volume logique. Par exemple, il peut ajouter ou supprimer les images redondantes d'un volume logique, changer le type de log d'un mirroir, ou désigner un volume logique comme dépôt de snapshot.

   Si la conversion nécessite l'allocation d'extents physique, l'allocation sera restreinte à ces extents physique. Si la conversion libère des extents physiques et qu'un ou plusieurs PV sont spécifiés, les extents physiques sont d'abords libérés depuis ces PV.

opérations

   Une seule de ces option est requise:

--cache, -H, --type cache Convertis un volume logique en LV cache avec l'utilisation d'un pool cache spécifié avec --cachepool.
--corelog identique à --mirrolog core
--merge Fusionne un snapshot dans son volume d'origine ou fusionne une image raid1 (qui a été splitée de son mirroir avec --trackchanges) dans son mirroir. Si les 2 volumes ne sont pas ouverts, la fusionne démarre immédiatement. Fusionner un snapshot dans un origine qui ne peut pas être fermé et diferré à la prochaine activation du volume. Durant la fusion, les lectures et écritures de l'origine apparaîssent comme s'ils étaient dirigés dans le snapshot à fusionner. Une fois terminé, le snapshot est supprimé. Plusieurs snapshots peuvent être spécifiés sur la ligne de commande ou un @tag peut être utilisé pour spécifier plusieurs snapshots.
--mirrorlog {disk|core|mirrored} Spécifie le type de log à utiliser. Défaut: disk, qui est persistant est nécessite peut d'espace disque, généralement sur un disques séparé. Core peut être utile pour les mirroirs à durée de vie courte: il signifie que le mirroir est regénéré en copiant les données depuis le premier périphérique à chaque fois que le périphérique est actuvé. mirrored créé un log persistant qui est lui-même mirroré.
--mirrors Spécifie le degré du mirroir à créer. Par exemple "-m 1" convertis le volume logique d'origine en un mirroir avec 2 parties; c'est à dire un volume linéaire avec une copie. Il y a 2 implémentations mirroir qui correspondent aux type de segment mirroir et raid1. le type par défaut est raid1.
--repair Répare un mirroir après une erreur disque et tente de fixer les métadonnées de pool thin. Par défaut, le nombre de mirroir d'origine sera restauré si possible. -y permet de répondre automatiquement aux questions. -f permet de ne rien remplacer. --use-policies utilise la stratégie de remplacement spécifiée dans lvm.conf. La réparation des pools thin ne peut se faisre que sur les volume thin inactifs. Il n'y a pas de validation des métadonnées entre le kernel et lvm2, et nécessite un travail manuel ultérieur. Une fois réparé, les anciennes métadonnées sont disponibles dans le LV "‹pool›_meta‹n›".
--replace Supprime le PV spécifié et le remplace avec un disponible dans le VG ou depuis la liste fournie. Seulement disponible pour les types de segment raid.
--snapshot Recréé un snapshot de volumes logique après avoir été séparés en utilisant --splitsnapshot.
--split Sépare le volume logique spécifié.
--splitcache Sépare le volume logique cache du pool de cache. Avant qu'il soit sortie du cache, le cache est vidé. Le volume est ainsi laissé inutilisé et peut être utilisé pour cacher un autre volume.
--splitsnapshot Sépare le volume logique snapshot spécifié de son origine. Le volume splitté contient les chunks qui diffèrent de l'origine avec les métadonnées les décrivant. Ce volume peut être effacé et détruit avec lvremove. l'inverse de --snapshot
--splitmirrors Spécifie le nombre d'images redondantes d'un mirroir à splitter pour former un nouveau volume logique. Un nom doit être fournis pour le nouveau LV avec --name, sauf si --trackchanges est spécifié
-T, --thin, --type thin Converti le volume logique en volume logique thin du pool thin spécifié avec --thinpool. Le volume logique original est renomé en un nouveau volume logique lecture-seule. utiliser --originname pour spécifier un nom. Le volume ne peut plus être modifié tant qu'il est utilisé comme volume d'origine externe pour les zones non-provisionnées d'un volume logique thin.
--type SegmentType Utilisé pour convertir un volume logique en un autre type de segment (cache, cache-pool, raid1, snapshot, thin, ou thin-pool). En convertissant un volume logique en LV cache, l'argument --cachepool est requis. En convertissant un volume logique en LV thin, --thinpool est requis.
--uncache décache le volume logique cache spécifié. Avant que le volume devienne non-caché, le cache est vidé. à la différence avec --splitcache le volume pool cache est supprimé. Cette option est l'inverse de --cahe.

OPTIONS

-b, --background Lance en tâche de fond
--cachepolicy Policy Définis la stratégie de cache. mq est le nom de la stratégie de base. smq est plus avancé.
--cachepool CachePoolLogicalVolume{Name|Path} Cet argument est nécessaire en convertissant un volume logique en LV cache.
--cachesettings Key=Value Définis les paramètres de cache.
-c, --chunksize ChunkSize[b|B|s|S|k|K|m|M|g|G] Donne la taille de chunk pour les volumes logique snapshot, pool cache et pool thin. Pour les snapshots, la valeur doit être en puissance de 2 entre 4Kib et 512Kib. Défaut: 4. pour les cache, la valeur doit être entre 32KiB et 1GiB, défaut: 64. pour les pools thin, la valeur doit être entre 64KiB et 1GiB.
--discards {ignore|nopassdown|passdown} Traitement des annulations par la couche thin dans le kernel et passé au volume physique.
-i, --interval ‹seconds› Interval d'affichage de la progression en %
--name Le nom à appliquer à un volume logique qui a été splitté depuis un volume logique mirroir
--noudevsync Désactive la synchronisation udev. Le processus n'attend pas de notification udev.
--oniginname NewExternalOriginVolumeName Le nouveau nom pour le volume logique original, qui devient le volume origine externe pour un volume logique thin. Sans cette option, le nom par défaut est "lvol‹n›" où ‹n› est le numéro LVM interne du volume logique. Ce volume sera lecture seule est ne peut plus être modifié tant qu'il est utilisé comme origine externe.
--poolmetadata PoolMetadataLogicalVolume{Name|Path} Spécifie les métadonnées cache ou thin. La taille devrait être entre 2Mio et 16Gio. Le pool cache est spécifié avec l'option --cachepool. Le pool thin est spécifié avec l'option --thinpool. Si le pool spécifié existe déjà, les métadonnée du pool seront placées dans le volume logique. Les propriétés du poor sont préservées par défaut. Il peut être utile pour réparer les métadonnées de pool ou pour redimensionner offline.
--poolmetadatasize PoolMetadataSize[b|B|s|S|k|K|m|M|g|G] Définis la taille des métadonnées du pool thin ou cache. La valeur par défaut est estimée avec (Pool_LV_size / Pool_LV_chunk_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 64bits).
--poolmetadataspare {y|n} Contrôle la création et la maintenance de métadonnées de volume logique spare utilisé pour la récupération automatique de pool. Seul un tel volume est maintenu dans un volume group avec une taille des plus grosses métadonnées de volume du pool. Défaut: yes.
-r, --readahead {ReadAheadSectors|auto|none} Définis le compteur de secteurs de readhead des métadonnées de volume logique du pool thin. Défaut: auto.
-R, --regionsize MirrorLogRegionSize Un mirroir est divisé en régions de cette taille (en Mo), et le log mirroir utilise cette granularité pour tracer quelles région sont en synchro
--stripes Indique le nombre de stripes. C'est égale au nombre de volumes physiques pour disperser le volume logique. Ne peut pas s'appliquer à un espace déjà alloué.
-I, --stripesize Indique le nombre de Ko pour la granularité des stripes. La tailles doit être une puissance de 2 mais ne peut excéder la taille d'extent physique.
--thinpool ThinPoolLogicalVolume{Name|Path} Spécifie ou convertis un volume logique en un volume de données de pool thin. Le contenu du volume convertis est perdu. Les métadonnées du volume logique du pool thin peuvent être spécifiés avec l'option --poolmetadata ou alloués avec --poolmetadatasize.
--trackchanegs Avec --splitmirrors dans un raid1, suit les changements pour que l'image lecture seul détacchée peut être fusionnée efficacement de nouveau dans le mirroir. Seul les régions du périphérique détaché où les données ont changés seront resynchronisés.
-Z, --zero {y|n} Contrôle les 0 des premiers 4Kio de données dans le snapshot. Si le volume est lecture seul, le snapshot ne sera pas mis à 0. Pour les volume thin il contrôle les 0 des blocks provisionnés. Noter que provisionner un grand nombre de chunks à 0 impacte les performances.

Exemples

Convertir le volume logique linéaire "vg00/lvol1" en volume logique mirroir:
lvconvert -m1 vg00/lvol1
Convertir le volume logique linéaire "vg00/lvol1" en volume logique RAID1:
lvconvert --type raid1 -m1 vg00/lvol1
Convertir un mirroir avec un log disque en un mirroir avec un log en mémoire:
lvconvert --mirrorlog core vg00/lvol1
Convertir un mirroir avec un log en mémoire en un mirroir avec un log disque:
lvconvert --mirrorlog disk vg00/lvol1
Convertir un volume logique mirroir en un volume logique linéaire:
lvconvert -m0 vg00/lvol1
Convertir un volume logique mirroir en un volume logique RAID1 avec le même nombre d'images:
lvconvert --type raid1 vg00/mirror_lv
Convertir le volume logique "vg00/lvol2" en snapshot du volume original "vg00/lvol1":
lvconvert -s vg00/lvol1 vg00/lvol2
Convertir un volume logique linéaire "vg00/lvol1" en mirroir, en utilisant des extents physiques /dev/sda:0-15 et /dev/sdb:0-15 pour l'allocation des nouveaux extents:
lvconvert -m1 vg00/lvol1 /dev/sda:0-15 /dev/sdb:0-15
Convertir le volume logique mirroir "vg00/lvmirror1" en linéaire, libérant les extents physiques de /dev/sda:
lvconvert -m0 vg00/lvmirror1 /dev/sda
Fusionner "vg00/lvol1_snap" dans son origine:
lvconvert --merge vg00/lvol1_snap
Si "vg00/lvol1", "vg00/lvol2" et "vg00/lvol3" sont tous taggés avec "some_tag" chaque volume logique snapshot sera fusionné en série. Si --background est utilisé il démarre la fusion des snapshots en parallèle:
lvconvert --merge @some_tag
Extrait une image du mirroir, créant un nouveau volume logique "lv_split". Le mirroir d'où l'image est extraite est réduite en accord. S'il y avait un mirroir 2-way (créé avec -m 1), le volume original résultant sera linéaire:
lvconvert --splitmirrors 1 --name lv_split vg00/lvmirror1
Un volume logique créé avec --type raid1 peut utiliser --trackchanges en splittant une image. Détacher une image du lv mirroir lv_raid1 comme périphérique lecture seul et suivre les changements:
lvconvert --splitmirrors 1 --trackchanges vg00/lv_raid1
Fusionner une image qui a été détachée temporairement de son mirroir avec --trackchanges dans son mirroir d'origine:
lvconvert --merge vg00/lv_raid1_rimage_1
Remplacer le volume physique /dev/sdb1 dans le volume logique RAID1 my_raid1 avec le volume physique /dev/sdf1.
lvconvert --replace /dev/sdb1 vg00/my_raid1 /dev/sdf1
Convertis le volume logique vg00/lvpool en un pool thin avec une taille de chunk de 128Kio et convertit vg00/lv1 en volume thin dans ce pool. le lv d'origine est utilisé comme origine externe d'origine, où toutes les écriture vers de tels volumes sont stockés dans le pool:
lvconvert --type thin --thinpool vg00/lvpool -c 128 lv1
Convertis le volume logique vg00/origin en volume thin dans le pool thin vg00/lvpool. Ce volume thin utilisera vg00/origin comme volume d'origine externe pour les zones non-provisionnées dans ce volume. L'origine externe utilise le nouveau nom vg00/external:
lvconvert -T --thinpool vg00/lvpool --originname external vg00/origin
Convertis un volume logique existant en LV pool cache utilisant les métadonnées de cache donnés:
lvconvert --type cache-pool --poolmetadata vg00/lvx_meta vg00/lvx_data
lvrename vg00/lvx_data vg00/lvx_cachepool
Convertis un volume logique existant en un LV cache dans le pool donné et une taille de chunk de 128Kio:
lvconvert --cache --cachepool vg00/lvx_cachepool -c 128 vg00/lvx
Détacher le pool cache d'un volume logique caché vg00/lvol1 existant et laisser le pool cache non-utilisé:
lvconvert --splitcache vg00/lvol1
Supprimer le pool cache d'un volume logique existant vg00/lvol1:
lvconvert --uncache vg00/lvol1
^
15 juin 2016

htmlpdflatexmanmd




lvcreate

lvcreate

Créer un volume logique

   lvcreate créé un nouveau volume logique dans un volume group en allouant des extents logiques dans le pool d'extents physiques disponibles dans ce volume group. S'il n'y a pas suffisamment d'extents physique, le volume group peut être étendu avec d'autres volumes physiques ou en réduisant des volumes logiques existants dans ce volume group. Si un ou plusieurs volumes physiques sont spécifiés, l'allocation d'extents physiques seront restreints à ces volumes. Le secondes forme supporte la création de volumes logiques snapshot qui conservent le contenu du volume logique original.

OPTIONS

-a|--activate [a][e|l|s]{y|n} Contrôle la disponibilité des volumes logiques à utiliser immédiatement après que la commande soit terminées. Par défaut, les nouveaux volumes logiques sont activés (-ay). -an laisse le nouveau volume logique inactif si possible. -aay, l'autoactivation est gérée avec un match dans activation/auto_activation_volume_list dans lvm.conf. -aey active exclusivement sur un nœud et -a{a|l}y active seulement sur le nœud local.
--addtag Tag Ajoute le tag spécifié. Peut être spécifié plusieurs fois
--alloc AllocationPolicy Sélectionne la stratégie d'allocation (anywhere|contiguous|cling|inherit|normal)
-A|--autobackup {y|n} Backup automatiquement les métadonnées après un changement
-H|--cache Crée un volume logique cache pour pool de cache. avec --extents ou --siwe, créé un volume logique cache. quand le nom du volume group est spécifié avec un volume logique existant qui n'est pas un pool cache, un tel volume est traité comme volume cache origine et un pool cache est créé. Dans ce cas --extents ou --size est utilisé pour spécifier la taille de volume pool cache.
--cachemode {passthrough|writeback|writethrough} Spécifie un mode de cache pour les écriture dans un lv cache. writeback,
--cachepolicy Policy Seulement pour les LV cache. Définis la stratégie de cache. mq est la stratégie de base, smq est plus avancé
--cachepool CachePoolLogicalVolume Spécifie le nom du volume pool cache. L'autre manière de spécifiée le nom du pool est d'ajouter le nom du VG en argument.
--cachesettings Key=Value Seulement pour les LV cache. Définis les paramètres cache.
-c|--chunksize ChunkSize Spécifie la taille de chunk pour les LV snapshot, pool cache et pool thin. Pour les snapshots, doit être une puissance de 2 entre 4Kio (défaut) et 512Kio. Pour les pools cache la valeur doit être un multiple de 32Kio entre 32Kio et 1Gio (défaut: 64Kio). Quand la taille est spécifiée avec le volume caching, elle ne peut pas être inférieur à la taille de chunk du pool cache. Pour les pools thin la valeur doit être un multiple de 64Kio (défaut) et 1Gio. allocation/thin_pool_chunk_size_policy dans lvm.conf sélectionne une stratégie de calcul différent.
--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-C|--contiguous {y|n} Définis ou redéfinis la stratégie d'alllocation contigüe pour les volumes logiques. Défaut: pas d'allocation contigüe
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
--discards {ignore|nopassdown|passdown} Définie le mode d'annulation pour le pool thin. Défaut: passdown.
--errorwhenfull {y|n} Configure le comportement d'un pool thin quand l'espace est remplis. Défaut: no. Le périphérique met ses opérations en queue jusqu'au timeoute. À yes, les opération I/O sont immédiatement mis en erreur.
-l|--extents LogicalExtentsNumber[%{FREE|ORIGIN|PVS|VG} Définis la taille du volume logique en unités d'extensions logique. avec '+' la valeur est ajoutée à la taille actuelle et sans, la valeur est absolue. Le nombre total d'extents physiques alloués sera supérieur, par exemple, si le volume est mirroré. Ce nombre peut également être exprimé en % de l'espace total dans le VG avec %VG, relatif à la taille existante du LV avec %LV, de l'espace restant dans le PV avec %PVS, en pourcentage de l'espace total du volume logique d'origine avec %ORIGIN. La valeur résultante est arrondis au supérieur.
-L|--size LogicalVolumeSize Définis la taille du volume logique en unité spécifiée. Avec un '+', la valeur est ajouté, sinon elle est prise comme valeur absolue.
-i|--stripes Stripes Indique le nombre de stripes pour l'extension. Non applicable aux LV utilisant le format de métadonnée original.
-I|--stripesize StripeSize Donne le nombre de ko pour la granularité des stripes.
-K|--ignoreactivationskip Ignore le flag skip des LV durant l'activation.
--ignoremonitoring Ne tente pas d'interragir avec dmeventd sauf si --monitor est spécifié
--minor Minor [-j|--major Major] Définis le numéro majeur et mineur. Non supporté avec les volumes pools. Ignoré avec les kernels récents
--metadataprofile ProfileName Sélectionne le profile de configuration des métadonnées à utiliser
-m|--mirrors Mirrors Créé un LV mirroir avec le nombre de copies spécifiée. avec --nosync, la création du mirroir saut la resynchronisation initiale. Toutes les données après seront mirrorée, mais le contenu original ne le sera pas.
--corelog|--mirrorlog {disk|core|mirrored} --corelog est équivalent à --mirrorlog. Spécifie le type de log à utiliser pour le mode mirror. disk créé une copie persistante des données. core signifie que le mirroir est regénéré en copiant les données du premier périphérique à chaque fois que le volume logique est activé, comme après un reboot. mirrored créé un log persistant qui est lui-même mirroré
--nosync N'effectue pas la resynchro initial à la création du mirroir
-R|--regionsize MirrorLogRegionSize] Un mirroir est divisé en région de la taille spécifiée, et le log mirroir utilise cette granularité pour suivre les régions à synchroniser.
--monitor {y|n} Active le monitoring d'un mirroir, snapshot ou pool thin avec dmeventd si installé. Si un périphérique utilisé par un mirroir monitoré reporte une erreur d'E/S, l'erreur est gérée en accord avec activation/mirror_image_fault_policy et activation/mirror_log_fault_policy dans lvm.conf
-n|--name LogicalVolume Définis le nom du nouveau volume logique
--noudevsync Désactive la synchronisation udev. Le processus n'attend pas de notification udev.
-p|--permission {r|rw} Définis les permissions d'accès. Défaut: rw
-M|--persistent {y|n} À yes, le numéro mineur est persistant. Les volumes pool ne peuvent pas avoir de numéros mineur et majeur persistants.
--poolmetadatasize MetadataVolumeSize Définis la taille des métadonnées du pool. Entre 2Mio et 16Gio pour les pool thin, jusqu'à 16Gio pour un pool cache. La valeur par défaut pour un thin pool est ((Pool_LV_size / Pool_LV_chunk_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 64b)
--poolmetadataspare {y|n} Contrôle la création et la maintenance de métadonnées de pool spare qui sont utilisés pour la récupération automatique du pool. Un seul volume est maintenu dans un volume group avec la taille des plus grosses métadonnées du pool.
--[raid]maxrecoveryrate Rate Définis le taux de récupération maximum pour un volume RAID. Le taux est spécifié comme quantité par seconde pour chaque périphérique dans l'array.
--[raid]minrecoveryrate Rate Définis le taux de récupération minimum pour un volume RAID. Le taux est spécifié comme quantité par seconde pour chaque périphérique dans l'array.
-r|--readahead {ReadAheadSectors|auto|none} Définis le compteur de secteur read ahead de ce volume logique.
-k|--setactivationskip {y|n} Contrôle si les volumes logiques sont flaggés pour être ignoré à l'activation. --ignoreactivationskip doit être utilisé. Le flag n'est pas appliqué durant la désactivation. Utiliser lvchange --setactivationskil pour changer le flag skip. voir activation/auto_set_activation_skip dans lvm.conf.
-s|--snapshot|-H|--cache {[VolumeGroup/]OriginalLogicalVolume Créé un LV snapshot pour un lv existant, appelé le lv d'origine. Un snapshot thin est créé quand l'origine est un volume thin et la taille n'est pas spécifiée. Un thin snapshot partage les même blocks dans le volume pool thin. Un snapshot de volume non thin avec la taille spécifié n'a pas besoin d'avoir la même quantité de stockage que l'origine, généralement 15-20% est suffisant. Note: une petite quantité d'espace allouée est utilisé pour suivre les emplacements des chunks de donnée. Si --thinpool est spécifié, un volume thin est créé et utilise le volume logique d'origine spécifié comme origine externe qui sert de blocks non-provisionnés. Seul les volumes lecture-seul peuvent être utilisés comme origine externe.
-V|--virtualsize VirtualSize Créé un périphérique provisionné léger ou un périphérique sparse. global/spase_segtype_default dans lvm.conf configure le type de segment sparse par défaut.
-t|--test Lance en mode test
-T|--thin Créé un pool thin ou un lv thin ou les 2. Avec --size et --extents, créé un lv pool thin. Avec --virtualsize, créé un lv thin dans le pool donné. Avec les 3 arguments, créé un pool thin et un lv utilisant ce pool.
--thinpool ThinPoolLogicalVolume Nom du volume pool thin.
--type SegmentType Créé un volume logique avec le type de segment spécifié. ( cache, cache-pool, error, linear, mirror, raid1, raid4, raid5_la, raid5_ls (= raid5), raid5_ra, raid5_rs, raid6_nc, raid6_nr, raid6_zr (= raid6), raid10, snapshot, striped, thin, thin-pool ou zero). Défaut: linear.
-v|--verbose Mode verbeux
-W|--wipesignatures {y|n} Contrôle l'effacement des signatures détectées dans le nouveau LV. Si cette option n'est pas spécifiée, la signature est remplie de 0 avec -Z. Peut être contrôlé avec allocation/wipe_signatures_when_zeroing_new_lvs dans lvm.conf. Si l'effacement blkid est utilisé allocation/use/blkid_wiping doit être définis. Les lv lecture seul ne sont pas effacés
-Z|--zero {y|n}] Remplis de 0 les 4Kio de données du début du lv. Défaut: yes. Les lv lecture seul ne sont pas effacés.

Exemples

Créer un lv striped avec 3 stripes, une taille de stripe de 8Kio et une taille de 100Mio dans le VG vg00
lvcreate -i 3 -I 8 -L 100M vg00
Créer un lv mirroir avec 1 copie et une taille de 500Mio utilisable
lvcreate -m1 --mirrorlog core -L 500M vg00
Créer un lv snapshot vg00/snap qui a accès au contenu de vg00/lvol1 à la date de création du snapshot. Si le lv d'origine contient un système de fichier, on peut monter le snapshot dans un répertoire arbitraire pour accéder au contenu du système de fichier pour lancer une sauvegarde tout en mettant à jours le système de fichier original
lvcreate --size 100m --snapshot --name snap /dev/vg00/lvol1
Créer un lv snapshot vg00/snap avec une taille de 20% du lv d'origine
lvcreate -s -l 20%ORIGIN --name snap vg00/lvol1
Créer un périphérique sparse nommé /dev/vg1/sparse de 1Tio avec un espace de 100Mio de données actuelles
lvcreate --virtualsize 1T --size 100M --snapshot --name sparse vg1
Créer un lv linéaire vg00/lvol1 utilisant les extents physiques /dev/sda:0-7 et /dev/sdb:0-7 pour l'allocation des extents
lvcreate -L 64M -n lvol1 vg00 /dev/sda:0-7 /dev/sdb:0-7
Créer un lv Raid5 5Gio vg00/my_lv avec 3 stripes (plus un disque de parité) et une taille de stripe de 64Kio
lvcreate --type raid5 -L 5G -i 3 -I 64 -n my_lv vg00
Créer un lv RAID5 vg00/my_lv, utilisant tout l'espace disque dans le VG et répartis sur tous les PV dans le VG
lvcreate --type raid5 -l 100%FREE -n my_lv vg00
Créer un RAID10 de 5Gio vg00/my_lv avec 2 stripes dans 2 mirroirs. Noter que les arguments -i et -m fonctionnent différemment:
lvcreate --type raid10 -L 5G -i 2 -m 1 -n my_lv vg00
Créé un lv pool de 100Mio pour du provisionning léger avec 2 stripes de 64Kio et un taille de chunk de 2156Kio avec un volume de 1Tio
lvcreate -i 2 -I 64 -c 256 -L100M -T vg00/pool -V 1T --name thin_lv
Créé un lv snapshot thin "thinsnap" du volume thin "thinvol" qui partagent les même blocks dans le pool thin. Noter que la taille ne doit pas être spécfiée sinon un snapshot non-thin est créé:
lvcreate -s vg00/thinvol --name thinsnap
Créer un volume snapshot thin d'un volume lecture seule inactif "origin" qui devient ensuite l'origine externe pour ce snapshot
lvcreate -s --thinpool vg00/pool origin
Créer un lv pool cache qui peut être utilisé pour cacher un volume logique
lvcreate --type cache-pool -L 1G -n my_lv_cachepool vg /dev/fast1
S'il y a un lv pool cache exsistant, créer un grand périphérique lent (le lv origine) et le lier au lv pool cache, créant un lv cache
lvcreate --cache -L 100G -n my_lv vg/my_lv_cachepool /dev/slow1
S'il y a un lv existant, créer le lv pool cache et le lier avec ce lv, créant un lv cache
lvcreate --type cache -L 1G -n my_lv_cachepool vg/my_lv /dev/fast1
^
24 mai 2016

htmlpdflatexmanmd




lvdisplay

lvdisplay

Affiche les attributs des volumes logiques

   lvdisplay permet de voir les attributs d'un volume logique. lvs est une alternative qui fournis les même informations dans le style ps.

OPTIONS

-a|--all Inclus les informations sur les volumes logiques interne tels que les mirroirs
-c|--colon Affiche la sortie en colonne.
--commandprofile ProfileName -d|--debug
--ignorelockingfailure Permet de traiter des opérations de métadonnées lecture-seule même si le module de lock échoue. Utile dans un script init si le répertoire de lock est monté en lecture seul.
--ignoreskippedcluster Permet de quitter avec un status non-zero si la commande est lancé sans lockup clusterisé et que certains vg clusterisés doivent être ignorés
--maps Affiche le mappage les extents logiques aux volumes physiques et aux extents physiques Pour mapper les extents physiques aux extents logique utiliser: pvs --segments -o +lv_name,seg_start_pe,segtype
--nosuffix Supprime le suffixe pour les tailles. Utiliser avec --units si besoin
-P|--partial Fait de son mieux pour fournir un accès aux volumes group qui sont seulement disponible partiellement
-S|--select Selection Affiche seulement les lignes qui matchent le critère donné
--units hHbBsSkKmMgGtTpPeE Toutes les tailles affichée sont exprimé avec l'unité spécifiée.
-v|--verbose Mode verbeux
-C|--columns Sortie séparée par des ':'
--aligned Utiliser avec --separator pour aligner les colonnes de sortie
--binary Utilise le valeurs binaire 0 ou 1 au lieu des valeurs litérale pour les colonnes qui ont exactement 2 valeurs valides
--noheadings Supprime les lignes d'en-tête
-o|--options [+|-|#]Field1[,Field2...] Liste de colonnes à afficher (-) ou enlever (-). '#' compacte les colonnes données. lv_all sélectionne toutes les colonnes de volume logiques, et lvseg_all sélectionne toutes les colonnes de segment de volume logique.
-O|--sort [+|-]Key1[,[+|-]Key2...] Liste de colonnes pour l'ordre de trie.
--separator Separator Chaîne à utiliser pour séparer chaque colonne
--unbuffered Produit une sortie immédiatement sant trier ou aligner les colonnes

Exemples

Afficher les attributs d'un volume logique
lvdisplay -v vg00/lvol2
Afficher les attributs d'un snaphot et le lv d'origine:
lvdisplay vg00/snapshot
^
24 mai 2016

htmlpdflatexmanmd




lvextend

lvextend

Étend la taille d'un volume logique

   lvextend permet d'étendre la taille d'un volume logique. Les extensions de lv snapshot sont également supportés. Mais pour changer le nombre de copies dans un volume logique mirroré, utiliser lvconvert.

OPTIONS

--alloc AllocationPolicy Sélectionne la stratégie d'allocation (anywhere|contiguous|cling|inherit|normal)
-A|--autobackup {y|n} Backup automatiquement les métadonnées après un changement
--commandprofile ProfileName Sélectionne le profile de configuration de commande
-f|--force Ne demande pas confirmation
-i|--stripes Stripes Indique le nombre de stripes pour l'extension. Non applicable aux LV utilisant le format de métadonné originel.
-I|--stripesize StripeSize Donne le nombre de ko pour la granularité des stripes.
-l|--extents [+]LogicalExtentsNumber[%{VG|LV|PVS|FREE|ORIGIN} Étend ou définis la taille du volume logique en unités d'extensions logique. avec '+' la valeur est ajoutée à la taille actuelle et sans, la valeur est absolue. Le nombre total d'extents physiques alloués sera supérieur, par exemple, si le volume est mirroré. Ce nombre peut également être exprimé en % de l'espace total dans le VG avec %VG, relatif à la taille existante du LV avec %LV, de l'espace restant dans le PV avec %PVS, en pourcentage de l'espace total du volume logique d'origine avec %ORIGIN. La valeur résultante est arrondis au supérieur.
-L|--size [+]LogicalVolumeSize[bBsSkKmMgGtTpPeE] Étend ou définis la taille du volume logique en unité spécifiée. Avec un '+', la valeur est ajouté, sinon elle est prise comme valeur absolue.
-n|--nofsck N'effectue pas de fsck avant d'étendre le système de fichier qu'en c'est nécessaire.
--noudevsync Désactive la synchronisation udev. Le processus n'attend pas de notification udev.
-r|--resizefs Redimensionne le système de fichier en même temps que le volume logique en utilisant fsadm
--use-policies Redimensionne le volume logique en accord avec la stratégie
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-t|--test Lance en mode test
-v|--verbose Mode verbeux

Exemples

Étend la taille du volume logique "vg01/lvol10" de 54MiO dans le volume physique /dev/sdk3. C'est seulement possible si /dev/sdk3 est un membre du volume groupe vg01 et qu'il y a suffisamment d'extents physique:
lvextend -L +54 /dev/vg01/lvol10 /dev/sdk3
Étend la taille du volume logique "vg01/lvol01" par la quantité totales dans le volume physique /dev/sdk3. C'est équivalent à spécifier "-l +100%PVS" sur la ligne de commande:
lvextend /dev/vg01/lvol01 /dev/sdk3
Étends un volume logique "vg01/lvol01" de 16Mio en utilisant les extents physiques /dev/sda:8-9 et /dev/sdb:8-9 pour allouer les extents:
lvextend -L+16M vg01/lvol01 /dev/sda:8-9 /dev/sdb:8-9
^
22 mai 2016

htmlpdflatexmanmd




lvm

lvm

Outils lvm2

   lvm fournis les outils en ligne de commande pour LVM2. Si lvm est invoqué sans arguments, affiche un prompt. Les commandes LVM peuvent être entrées directement.

   Si lvm est invoqué avec argv[0] définis au nom d'une commande spécifique, il agit comme cette commande

   À l'invocation, lvm nécessite seulement que les descripteurs de fichier stdin, stdout et stderr soient disponible. Si d'autres sont trouvés, ils sont fermés et des messages l'alerte sont émis.

   Là où les commandes prennent des noms VG ou LV en argument, le chemin complet est optionnel. Un LV appelé lvol0 dans un VG appelé vg0 peuvent être spécifiés sous la forme vg0/lvol0. Quand une liste de VG est requise mais laissée vide, une liste de tous les VG sera substituée. Quand une liste de LV est requise main un VG est donné, une liste de tous les LV dans ce VG est subsitué.

   Un avantage d'utiliser le shell intégré est que les informations de configuration sont mis en cache en interne entre les commandes.

   Un fichier contenant un simple script avec une commande par ligne peut également être donné sur la ligne de commande. Le script peut également être exécuté directement si la première ligne est #! suivie par le chemin de lvm.

Commandes intégrées

   Les commandes suivantes sont intégrées dans lvm sans liens créés dans le système de fichier.

config =lvmconfig
devtypes Affiche les types de périphériques block intégrés reconnus
formats Affiche les formats de métadonnées reconnus
help Affiche l'aide
lvpoll Opérations lvmpolld complet
pvdata Non encore implémenté
segtypes Affiche les types de segments LVM reconnus
systemid Affiche tout system ID actuellement définis dans cet hôte
tags Affiche tous les tags définis dans cet hôte
version Affiche la version

Commandes

   Les commandes suivantes implémentent les fonctionnalité de cœur de LVM

pvchange Change les attributs d'un volume physique
pvck Vérifie les métadonnées d'un volume physique
pvcreate Initialise un disque ou une partition à utiliser par LVM
pvdisplay Affiche les attributs d'un volume physique
pvmove Déplace les extents physiques
pvremove Supprime un volume physique
pvresize Redimensionne un disque ou une partition utilisé par lvm
pvs Affiche des informations sur les volumes physique
pvscan Scanne tous les disques pour les volumes physique
vgcfgbackup Sauvegarde la zone de descripteur de volume group
vgcfgrestore Restaure la zone de descripteur de volume group
vgchange Change les attributs d'un volume group
vgck Vérifie les métadonnées d'un volume group
vgconvert convertis le format de métadonnées d'un volume group
vgcreate Créé un volume group
vgdisplay Affiche les attributs d'un volume group
vgextend Ajoute des volumes physiques à un volume group
vgimport rend les volumes group exportés connus du système
vgimportclone Importe et renomme des volume group dupliqués
vgmerge Fusionne 2 volumes group
vgmknodes Recréé un répertoire de Volume Group et les fichier spéciaux de volume logique
vgreduce Réduit un volume group en supprimant un ou plusieurs volumes physique
vgremove Supprime un volume group
vgrename Renomme un volume group
vgs Affiche des informations sur les volume group
vgscan Scanne tous les disques pour les volumes group et reconstruit les caches
vgsplit Split un volume group en 2, en déplaçant les volumes logiques d'un volume group vers un autre en déplaçant tous les volumes physiques
lvchange Change les attributs d'un volume logique
lvconvert Convertis un volume logique d'un linéaire vers un mirror ou un snapshot
lvcreate Créé un volume logique dans un volume group existant
lvdisplay Affiche les attributs d'un volume logique
lvextend Étend la taille d'un volume logique
lvmchange Change les attributs de LVM
lvmconfig Affiche les informations de configuration après avoir chargé lvm.conf et autres fichiers de configuration
lvmdiskscan Scanne tous les périphériques visible pour LVM2
lvmdump Créé des dump d'informations lvm2 pour diagnostique
lvreduce Réduit la taille d'un volume logique
lvremove Supprime un volume logique
lvrename renomme un volume logique
lvresize Redimensionne un volume logique
lvs Affiche des informations sur les volumes logique
lvscan Scanne tous les disque pour les volumes logique

   Les commande suivantes ne sont pas encore implémentées mais le seront dans le future: lvmadc, lvmsar, pvdata.

OPTIONS

   Les options suivantes sont disponible pour de nombreuses commandes. Elles sont implémentées de manière générique et documentés ici au lieu des man individuels

-v, --verbose mode verbeux
-d, --debug définis le niveau de débug, de 1 à 6 fois pour augmenter les détails.
-q, --quiet Supprime la sortie et les messages de log. Supprime également tout prompt et répond automatiquement no
--yes Par de prompt et répond toujours yes
-t, --test Lance en mode test. Les commandes ne mettent pas à jours les métadonnées.
--driverloaded {y|n} à n, ne tente pas de contacter le pilote device-mapper du kernel
-A, --autobackup {y|n} Backup automatiquement les métadonnées après un changement.
-P, --partial Définis, les outils fond de leur mieux pour fournir un accès aux volumes group qui sont seulement disponible partiellement. Quand un partie d'un volume logique est manquant, /dev/ioerror est substitué, et dmsetup peut être utilisé pour retourner les erreurs I/O.
-S, --select ‹selection› Pour les commandes de rapport, affiche seulement les lignes qui matchent le critère donné.
-M, --metadatatype Type$ Spécifie quel type de métadonnée utiliser, tel que lvm1 ou lvm2.
--ignorelockingfailure Permet de traiter des opérations de métadonnées lecture-seule tel que lvchange -ay et vgchange -ay même si le module de lock échoue. Utile dans un script init si le répertoire de lock est monté en lecture seul.
--ignoreskippedcluster Permet de quitter avec un status non-zero si la commande est lancé sans lockup clusterisé et certains vg clusterisés doivent être ignorés.
--readonly Lance la commande en mode spécial lecture seul qui lit les métadonnées sur disque sans nécessiter de créer un lock.
--foreign Force la commande à accéder aux volumes groupe exterieur. PEut être utilisé pour reporter ou afficher un VG qui est possédé par un autre hôte. Les performances peuvent être très réduite parce que le cache lvmetad n'est pas utilisé
--shared Accède à un volume group partagé, qui serait ignoré quand lvmlockd n'est pas utilisé.
--addtag tag Ajoute le tag spécifié à un PV, VG ou LV. Peut être spécifié plusieurs fois. Les tags peuvent être donné sur la ligne de commande à la place des arguments PV, VG, ou LV.
--deltag tag Supprime le tag spécifié
--alloc {anywhere|contiguous|cling|inherit|normal} Sélectionne la stratégie d'allocation quand une commande doit allouer des Extents physiques depuis le Volume Group. Chaque Volume Group et Logical Volume a une stratégie d'allocation définie. Défaut pour VG: normal, LV: inherit

        normal Applique des règles de sens commun qui ne place pas les stripes parallèles dans le même volume physique.
        inherit applique la même stratégie que le VG
        contiguous Nécessite que les nouveaux extents soient placé adjacent aux extents physique existant
        cling Place le nouvel extent physique sur le même volume physique que les extents physique dans le même stripe du volume logique

--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser en traitant une commande LVM.
--metadataprofile ProfileName Sélectionne le profile de configuration des métadonnées à utiliser en traitant une commande LVM.
--profile ProfileName idem à --metadataprofile pour vgcreate, lvcreate, vgchange et lvchange, et --commandprofile pour les autres commandes.
--config ConfigString Configuration à utiliser

Allocation

   Quand une opération doit allouer des Extents physique pour un ou plusieurs volumes physique, les outils traitent comme suit:

   Tout d'abord, ils génèrent le jeu complet d'Extents Physique non-alloués dans le Volume Group. Si une plage d'Extents sont fournis à la fin de la ligne de commande, seul les Extents physique non-alloués dans cette plage dans les volumes physique spécifiés sont considérés.

   Ensuite, ils tentent chaque stratégie d'allocation en retour, en commençant la stratégie la plus stricte (contiguous) et se termine avec la stratégie spécifiée avec --alloc ou la valeur par défaut. Pour chaque stratégie, en commençant depuis l'Extent logique avec le numéro le plus faible de l'espace du volume logique vide qui doit être remplis, ils allouent autant d'espace que possible en accord avec les restrictions imposées par la stratégie. Si plus d'espace est nécessaire, ils utilise la stratégie suivante.

   Les restrictions sont les suivantes:

   Contiguous nécessite que l'emplacement physique d'un extent logique qui n'est pas le premier extent logique d'un volume logique soit adjacent à l'emplacement physique de l'extent logique le précédent immédiatement.

   Quand un volume logique est stripé ou mirroré, les restrictions ci-dessus sont appliquées indépendamment à chaque stripe ou image mirroir qui nécessite de l'espace.

   Normal ne choisit pas un Extent Physique qui partage le même volume physique comme Extent Logique déjà alloué à un volume logique parallèle (ex: un striped ou une image mirroir différente) au même offset dans ce volume logique parallèle.

Types de volume logique

   Certains types de volumes logiques sont simple à créer et peut être fait avec une simple commande lvcreate. Les types de volume logique linear et striped en sont un exemple. D'autre types de volume logique peuvent nécessiter plus d'une commande pour les créer, comme les types cache et thin provisioning.

Critères de Sélection

   Les critères de sélection sont un jeu de déclaration combinés par des opérateurs logique et de groupement. La déclaration consiste de nom de colonne pour lequel un jeu de valeurs valides est définis en utilisant des opérateurs de comparaison. Pour une liste complète de noms de colonne qui peuvent être utilisé dans la sélection, voir la sortie de ‹commande lvm› -S help

Opérateurs de comparaison (cmp_op)

=~ Matche l'expression régulière
!~ ne match pas l'expression régulière
= égal à
!= Non égal à
›= Supérieur ou égal à
Supérieur à
‹= Inférieur ou égal à
Inférieur à

Opérateurs logiques binaire (cmp_log)

&& Tous les champs doivent matcher
, Idem
|| Au moins un champs doit matcher
# idem

Opérateurs logique unaire

! Négation

Opérateurs de groupement

() parenthèses
[] Liste
{} Sous-jeu de liste

Spécification de grammaire informelle

   STATEMENT = column cmp_op VALUE | STATEMENT log_op STATEMENT | (STATEMENT) | !(STATEMENT)

Variables d'environnement

HOME Répertoire contenant .lvm_history si le shell readline interne est invoqué
LVM_COMAND_PROFILE Nom du profile de commande par défaut à utiliser pour les commandes LVM.
LVM_SYSTEM_DIR Répertoire contenant lvm.conf. Défaut: /etc/lvm
LVM_SUPPRESS_FD_WARNINGS Supprime les alertes sur les descripteurs de fichier inattendus passés à lvm
LVM_VG_NAME Nom deu volume group qui est assumé pour toute référence à un volume logique qui ne spécifie pas de chemin.
LVM_LVMETAD_PIDFILE Nom du volume group qui stocke l'ID du process lvmetad
LVM_LVMETAD_SOCKET Chemin du socket utilisé pour communiquer avec lvmetad
LVM_LVMPOLLD_PIDFILE Chemin du fichier qui stocke l'ID du processus lvmpolld
LVM_LVMPOLLD_SOCKET Chemin du socket utilisé pour communiquer avec lvmpolld
LVM_LOG_FILE_EPOCH Chaîne jusqu'à 32 lettre à ajouter au nom du fichier de log et suivi par l'ID du processus et un horodatage. Si définis, chaque processus log dans un fichier séparé
LVM_EXPECTED_EXIT_STATUS Le status anticipé quand le processus quitte. Utiliser "›N" pour matcher un status supérieur à N
LVM_SUPPRESS_LOCKING_FAILURE_MESSAGES Utilisé pour supprimer les messages d'alerte quand le lock configuré est indisponible
DM_ABORT_ON_INTERNAL_ERRORS Annule le traitement si le code détecte une erreur interne non-fatal
DM_DISABLE_UDEV Évite l'interaction avec udev. LVM va gérer les nœud dans /dev directement
^
23 mai 2016

htmlpdflatexmanmd




lvm-config

lvm-config, lvm-dumpconfig

Afficher la configuration LVM

   lvmconfig produit une sortie formattée de la configuration LVM. La comme a une forme identique à lvm dumpconfig

OPTIONS

-f, --file Envoie la sortie dans le fichier spécifié
-l, --list Liste les paramètres de configuration avec commentaire. Identique à lvmconfig --type list --withsummary
--type {current|default|diff|full|missing|new|profilable|profilable-command|profilable-metadata} Sélectionne le type de configuration à afficher.

        current Affiche la configuration lvm.conf courante
        default Affiche les paramètres de configuration assignés avec les valeurs par défaut
        diff Affiche tous les paramètres de configuration pour lesquels les valeurs diffèrent de la valeur par défaut
        full Affiche toute l'arborescence de configuration.
        list Affiche une liste des paramètres de configuration
        missing Affiche tous les paramètres de configuration avec des valeurs par défaut qui sont manquant dans la configuration courante
        new Affiche tous les nouveaux paramètres de configuration introduit par la version courante de LVM (ou spécifiée avec --atversion)
        profilable Affiche tous les paramètres de configuration profilable avec des valeurs par défaut.
        profilable-command Affiche tous les paramètres de configuration profilable avec les valeurs assignées qui peuvent être utilisés dans les profile de commande
        profilable-metadata Affiche tous les paramètres de configuration profilable avec les valeurs assignées qui peuvent être utilisés dans les profile de métadonnées

--atversion Spécifie une version LVM au format x.y.z. Pour limiter l'affichage des paramètres
--sinceversion Idem, applicable seulement avec --type new
--ignoreadvanced Exclus les paramètres de configuration avancés
--ignoreunsupported Exclus les paramètres de configuration non-supportés
--ignorelocal Ignore la section local
--config Utilise la chaîne spécifiée pour remplacer la configuration existante
--commandprofile Utilise le profile spécifié pour remplacer la configuration existante
--profile Identique à --commandprofile mais la configuration n'est pas appliquée pour la commande lvmconfig
--metadataprofile Spécifie le profile pour remplacer la configuration existante
--mergedconfig Quand la commande lvmconfig est lancée avec --config option et/ou --commandprofile (ou avec la variable d'environnement LVM_COMMAND_PROFILE), --profile, --metadataprofile, fusionne tout le contenu de la configuration avant de l'afficher
--showdeprecated Inclus les paramètres de configuration dépréciée dans la sortie
--showunsupported Inclus les paramètres de configuration non-supportés
--validate Valide la configuration courante utilisée et quitte avec un code de sortie approprié
--withsummary Affiche une ligne de commantaire pour chaque nœud de configuration
withcomments Affiche un commentaire complet pour chaque nœud de configuration.
--withspaces Quand approprié, ajoute plus d'espace dans la sortie pour une meilleur lisibilité
--withversions Affiche également un commentaire contenant la version d'introduction pour chaque nœud de configuration.
^
22 mai 2016

htmlpdflatexmanmd




lvm.conf

lvm.conf

Fichier de configuration pour LVM2

   lvm.conf est chargé durant l'initialisation de lvm. Ce fichier peut en retour charger d'autres fichiers.

   Les paramètres définis dans lvm.conf peuvent être remplacés par une des méthodes de configuration étendues suivantes:

   - Configuration spécifiée sur la ligne de commande en utilisant --config.

   Un profile est un jeu de paramètres de configuration personnalisable sélectionné. Il y a 2 groupes de profile: les profiles de commande et les profiles de métadonnées.

   - Le profile de commande est utilisé pour écraser les paramètres de configuration au niveau de la commande lvm globale. Il est appliqué au début de l'exécution de la commande lvm et est utilisé tout le temps de l'exécution de la commande. Le profile de commande est appliqué avec --commandprofile.

   - Le profile de métadonnées est utilisé pour écraser les paramètres de configuration au niveau Volume Group/Logical Volume. Il est appliqué indépendamment pour chaque VG/LV qui est traité. Ainsi, chaque VG/LV peut stocker le nom de profile utilisé dans ses métadonnées pour que le profile s'applique automatiquement quand ce VG/LV est traité. Le profile de métadonnée peut être spécifié avec --metadataprofile et --detachprofile. les commande de reporting fournissent -o vg_profile et -o lv_profile pour affiche le profile de métadonnées actuellement attachés au VG/LV.

   Le jeu d'options permis pour les profiles de commande est mutuellement exclusif quand il est comparé avec le jeu d'options permis pour les profiles de métadonnées. Les paramètres qui appartiennent aux 2 set ne peuvent être mixés ensemble et les outils LVM vont rejeter de tels profiles.

   LVM lui-même fournis quelques profiles de configuration prédéfinis. Les utilisateurs sont autorisés à ajouter plus de profile avec différentes valeurs si nécessaire. Dans ce but, il y a la commande profile_template.profile (pour les profiles de commande) et metadata_profile_template.profile (pour les profiles de métadonnées) qui contient tous les paramètres qui sont personnalisable par profiles d'un certain type. Les utilisateurs sont encouragés à copier ces templates et de les éditer si nécessaire. Alternativement, lvmconfig --file ‹profilename› --type profilable-commande ‹section› ou lvmconfig --file ‹profilename› --type profilable-metadata ‹section› peuvent être utilisé pour générer une configuration avec des paramètres profilables dans un des type pour la section donné et de les sauver dans le nouveau profile. Si la section n'est pas spécifiée, tous les paramètres profilables sont reportés.

   Les profiles sont stockés dans /etc/lvm/profile par défaut. Cet emplacement peut être changé en utilisant le paramètres config/profile_dir. Chaque configuration de profile est stocké dans un fichier ProfileName.profie dans le répertoire de profile.

   Quand plusieurs méthodes de configuration sont utilisés en même temps et que lvm recherche la valeur d'un paramètre particulier, il traverse la configuration en cascade de gauche à droite:

   Ligne de commande -› profile de commande -› profile de métadonnées -› config de tag -› lvmlocal.conf -› lvm.conf

   S'il n'y a pas de paramètre trouvé à la fin de la cascade, une valeur par défaut est utilisée pour ce paramètre. Utiliser lvmconfig pour vérifier les paramètres utilisés et leur valeurs par défaut.

Syntaxe

   Les espaces blancs ne sont pas significatif sauf dans dans les guillemets. Grammaire informelle:

file = value* Un fichier de configuration consiste d'un jeu de valeurs
value = section | assignment Une valeur peut être soit une nouvelle secion, ou un assignement
section = identifier '{' value* '}' Une section regroupe des valeurs associées ensemble. Si la même section est rencontrée plusieurs fois, le contenus de toutes les instances sont concaténés ensemble dans l'ordre où elles apparaissent. Elle est dénotée par un nom et délimitée par des {}
assignment = identifier '=' ( array | type ) Un assignement associe un type avec un identifiant. Si l'identifiant contient des barres obliques, ils sont interprétés comme délimiteur de chemin. La déclaration section/key = value est équivalente à section { key = value }. Si plusieurs instances de la même clé est rencontrée, seule la dernière valeur est utilisé (et une alerte est émise).
array = '[' ( type ',')* type ']' | '[' ']' les tableaux non-homogènes sont supportés. Un tableau vide est acceptable
type = integer | float | string integer = [0-9]* ; float = [0-9]*'.'[0-9]* ; string = '"'.*'"'

Paramètres

   La commande lvmconfig affiche les paramètres de configuration LVM dans divers formats.

Affiche une liste de tous les paramètres de configuration possible, avec leur valeurs par défaut.
lvmconfig --type default
Idem, avec commantaires:
lvmconfig --type default --withcomments
idem avec les valeurs courantes:
lvmconfig --type current
Affiche tous les paramètres configurés avec une valeur différente du défaut:
lvmconfig --type diff
Affiche un simple paramètre avec sa valeur par défaut, description, où Section réfère à la section de configuration:
lvmconfig --type default --withcomments Section/Setting
^
23 mai 2016

htmlpdflatexmanmd




^
22 mai 2016

htmlpdflatexmanmd




lvmcache

lvmcache

Cache LVM

   Le type de volume logique cache utilise un LV petit et rapide pour améliorer les performances d'un LV grand et lent. Il stocke les blocks fréquemment utilisé dans le LV rapide. Il est appelé le pool cache, et le grand LV est appelé l'origine. À cause des requis de dm-cache (le pilote kernel), lvm split le LV pool dans 2 périphériques - le LV de données de cache et LV de métadonnées de cache. Le LV de données de cache contient les blocks de données copiées. Le LV de métadonnées de cache maintient les informations d'audit qui spécifie où les blocks sont stockés. Les utilisateurs devraient être familiarisés avec ces LV s'ils souhaitent créer le meilleur LV caché possible Tous les LV associés doivent être dans le même VG

Utilisation du cache

   La méthode principale pour utiliser un LV de type cache:

0. créer OriginLV

Créé un LV ou identifie un LV origine existant
lvcreate -n OriginLV -L LargeSize VG SlowPVs
Exemple:
lvcreate -n lvol0 -L 100G vg

1. créer CacheDataLV

1. créer CacheDataLV
Créé le LV de métadonnées de cache. Ce LV maintient les blocks depuis OriginLV. La taille de ce LV est la taille du cache. Exemple:
lvcreate -n Cache0meta -L 12M vg /dev/fast

2. créer CachePoolLV

Combine les 2 LV en un LV pool.
lvconvert --type cache-pool --poolmetadata vg/cache0meta vg/cache0

3. Créer CacheLV

Créé un LV cache en liant le LV pool au LV origine.
lvconvert --type cache --cachepool vg/cache0 vg/lvol0

Suppression du cache

Un LV pool peut être déconnecté d'un LV Cache, laissant un LV pool inutilisé, et un LV origine sans cache:
lvconvert --splitcache vg/cache0
Supprimer un LV pool sant supprimer sont LV origine lié:
lvremove vg/CachePoolLV
Une commande alternative déconnecte également le pool du cache, et supprime le pool:
lvconvert --uncache vg/cacheLV
Supprimer un LV cache supprime le LV origine et le LV pool lié
lvremove vg/CacheLV

Tolérance d'erreurs dans un LV pool.

0. Créer un LV origine:
lvcreate -L 10G -n lv1 vg /dev/slow_devs
1. Créer un cache LV data RAID1:
lvcreate --type raid1 -m 1 -L 1G -n cache1 vg /dev/fast1 /dev/fast2
2. Créer un cache LV métadonnée RAID1:
lvcreate --type raid1 -m 1 -L 8M -n cache1meta vg /dev/fast1 /dev/fast2
3. Créer un LV pool combinant le LV data et le LV metadata:
lvconvert --type cache-pool --poolmetadata vg/cache1meta vg/cache1
4. Créer un LV cache en combinant le LV pool et le LV origine
lvconvert --type cache --cachepool vg/cache1 vg/lv1

Mode de cache

   Le mode de cache par défaut est "writethrough". Ce mode s'assure que toute donnée écrite sera stocké dans le pool et dans l'origine. La perte d'un périphérique associé avec le pool dans ce cas ne signifie pas la perte d'une donnée.

   Un autre mode de cache, "writeback" retarde l'écriture des blocks de données du pool dans l'origine. Ce mode augmente les performances, mais la perte d'un périphériques du pool peut résulter de pertes de données.

   Avec l'options --cachemode, le mode peut être définis en créant un cache, ou changé sur un cache existant.

Exemples

Créer un LV origin:
lvcreate -L 10G -n lv1 vg /dev/slow
Créer un cache LV data:
vcreate -L 1G -n cache1 vg /dev/fast
Créer un cache LV metadata
lvcreate -L 8M -n cache1meta vg /dev/fast
Créer un cache LV pool
lvconvert --type cache-pool --poolmetadata vg/cache1meta vg/cache1
Créer le cache:
lvconvert --type cache --cachepool vg/cache1 --cachemode writethrough vg/lv1

Stratégie de cache

   Le sous-système de cache a des paramètres additionnels par LV: la stratégie de cache à utiliser. 3 stratégie sont actuellement disponible: smq est la stratégie par défaut, m. est une ancienne implémentation, et cleaner est utilisé pour forcer le cache à vider toutes les écritures en cache sur l'origin

   La stratégie mq a des paramètres. Les défaut sont choisis pour être convenable pour la majorité des systèmes, mais dans des circonstances spéciales, changer ces paramètres peuvent améliorer les performances.

   Avec les options --cachepolicy et --cachesettings, la stratégie de cache et les paramètres peuvent être définis en créant un cache, ou changé dans un cache existant.

Exemple

Changer la stratégie d'un cache existant:
lvchange --cachepolicy mq --cachesettings 'migration_threshold=2048 random_threshold=4' vg/lv1
Dans lvm.conf:
allocation/cache_policy
allocation/cache_settings

Taille de chunk

   La taille de blocks de données gérés par un pool peut être spécifié avec l'option --chunksize à la création. La valeur doit être un multiple de 32KiO entre 32KiO et 1GiO.

   Utiliser une taille de chunk qui est trop grande réduit l'utilité du cache. Cependant, une taille trop petite surcharge le travail de gestion des chunks qui sont mappés dans le cache.

Pour afficher la taille de chunk du cache:
lvs -o+chunksize VG/CacheLV
Dans lvm.conf:
cache_pool_chunk_size
Pour connaître la valeur par défaut:
lvmconfig --type default allocation/cache_pool_chunk_size

Automatic pool metadata LV

   Un LV data peut être convertit au LV pool sans spécifier de LV métadonnée. LVM va automatiquement créer un LV métadonnées depuis le même VG.

Créer un nouveau cache sans un LV origine existant

Un LV cache peut être créé en utilisant un pool sans un LV origine existant. Un nouveau LV origin est créé et lié au pool en une étape
lvcreate --type cache -L LargeSize -n CacheLV --cachepool VG/CachePoolLV VG SlowPVs

Création de LV pool en une seule étape

Un LV pool peut être créé en une seule commande, au lieu d'utiliser lvconvert sur des LV existant:
lvcreate --type cache-pool -L CacheSize -n CachePoolLV VG FastPVs

Convertir des LV existant en type cache

Quand un LV origine existant est convertis en LV cache, le pool spécifié peut être un LV normal, au lieu d'un LV pool. Dans ce cas, lvm convertis le LV normal en cache. Un LV metadata peut optionnellement être spécifié.
lvcreate -n OriginLV -L LargeSize VG
lvcreate -n CacheDataLV -L CacheSize VG
lvconvert --type cache --cachepool VG/CataDataLV VG/OriginLV
C'est équivalent à
lvcreate -n OriginLV -L LargeSize VG
lvcreate -n CacheDataLV -L CacheSize VG
lvconvert --type cache-pool VG/CacheDataLV
lvconvert --type cache --cachepool VG/CachePoolLV VG/OriginLV
^
23 mai 2016

htmlpdflatexmanmd




lvmconf

lvmconf

Modifier la configuration LVM

   lvmconf est un script qui modifie la configuration dans un fichier de configuration lvm. De plus, il peut également définir le service systemd ou SysVinit en accord avec les changements dans la configuration lvm si nécessaire.

OPTIONS

--disable-cluster Définis locking_type au type par défaut non-clusterisé. reset également lvmetad à son défaut.
--enable-cluster Définis locking_type au type par défaut clusterisé dans ce système. Désactive également l'utilisation de lvmetad vu qu'il ne supporte pas les environnements clusterisés
--enable-halvm Définis locking_type utilisable pour l'utilisation LVM HA. Désactive également lvmetad vu qu'il ne supporte pas les environnements LVM HA.
--disable-halvm Définis locking_type au type par défaut non-clusterisé. reset également lvmetad à son défaut.
--file ‹configfile› Applique les changements dans le fichier spécifié. Défaut: /etc/lvm/lvm.conf
--lockinglib ‹lib›, --lockinglibdir ‹dir› Définis la librairie de locking à charger si un type de locking externe est utilisé
--services En plus de définir la configuration, active/désactive les services clvmd et lvmetad. Ce script ne configure pas les services fournis par les agents de ressource cluster.
--mirrorservice Active/désactive également le service optionnel cmirrord en manipulant les services (applicable seulement avec --services)
--startstopservices démarre/stoppe immédiatement les services (applicable seulement avec --services)
^
16 juin 2016

htmlpdflatexmanmd




lvmdbusd

lvmdbusd

Service qui fournis une API D-Bus à LVM

OPTIONS

--debug Mode debug
--udev Utilise les événements udev pour déclencher les mises à jours
^
23 mai 2016

htmlpdflatexmanmd




lvmdiskscan

lvmdiskscan

Scanne les périphériques LVM2 visibles

   lvmdiskscan recherche tous les disques SCSI, (E)IDE, md et d'autres types de périphériques block dans le système à la recherche de volumes physiques LVM. La taille reportée est la taille du périphérique réel. Définir un filtre dans lvm.conf pour restreindre le scan pour éviter un CDROM par exemple.

OPTIONS

-l, --lvmpartition Reporte uniquement les volumes physiques
--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-v|--verbose Mode verbeux
^
23 mai 2016

htmlpdflatexmanmd




lvmdump

lvmdump

Créé des dumps d'information lvm2 pour diagnostique

   lvmdump est un outil pour dumper diverses informations sur lvm2. Par défaut, il créé un tarball. Le contenu est le suivant:

- Informations dmsetup
- Table de processus en cours d'exécution
- Entrées récentes dans /var/log/messages
- Configuration lvm complète et cache
- Liste les nœuds présents sous /dev
- Liste des fichiers présent dans /sys/block
- Liste des fichiers présent dans /sys/devices/virtual/block
- (-m) dump des métadonnées
- (-a) Sortie debug de vgscan pvscan et liste tous les pv, vg et lv disponibles
- (-c) information du status de cluster
- (-l) État lvmetad
- (-p) État lvmpolld
- (-s) informations et contexte système
- (-u) informations et contexte udev

OPTIONS

-a Informations avancée. Si lvm est blocké, ce script peut blocker également.
-c si clvmd est en cours de fonctionnement, récupère les informations de cluster également
-d dir Dump dans un répertoire au lieu d'un tar.
-l Inclus l'état lvmetad
-m Collecte les métadonnées
-p Inclus l'état lvmpolld
-s informations et contexte système
-u informations et contexte udev

Variables d'environnement

LVM_BINARY Le binaire LVM2 à utiliser. Défaut: lvm
DMSETUP_BINARY binaire dmsetup à utiliser. Défaut: dmsetup
^
23 mai 2016

htmlpdflatexmanmd




lvmetad

lvmetad

Service de cache de métadonnées lvm

   Le service met en cache les métadonnées pour que les commandes lvm puissent les lire sans scanner les disques. Le cache peut être un avantage parce que scanner les disques consomme du temps et peut interférer avec le fonctionnement du système et des disques.

   lvmetad ne lit pas les métadonnées depuis le disque lui-même. la commande pvscan --cache scanne les disque, lit les métadonnées et les envoie à lvmetad.

   Les nouveaux disques LVM qui apparaîssent dans le système doivent être scannés par pvscan avant que lvmetad les connaisse. Si lvmetad ne connaît pas les disques, les commandes lvm utilisant lvmetad ne les connaissent pas. Quand des disques sont ajoutés ou supprimés du système, lvmetad doit être mis à jours.

   lvmetad est généralement combiné avec des services basés sur les événements qui lancent automatiquement pvscan -- cache sur les nouveaux disques. De cette manière, le cache lvmetad est automatiquement mis à jours. Les règle udev lvm et les services systemd implémentent cet automatisme.

   Si lvmetad est démarré ou redémarré après avoir ajouté des disques au système, ou si le global_filter a changé, le cache doit être mis à jours.

   L'utilisation de lvmetad est géré dans lvm.conf par l'option global/use_lvmetad (voir lvmconfig --withcomments global/use_lvmetad)

   Pour ignorer des disques lvm au niveau système, utiliser devices/global_filter

OPTIONS

-l level[,level...] Spécifie les niveaux de log des messages à générer, séparés par une ','.
-p pidfile_path Chemin du fichier pid. Défaut: /run/lvmetad.pid
-s socket_path Chemin du socket. Défaut: /run/lvm/lvmetad.socket
-t timeout_value Délai d'inactivité avant que le service se termine. À 0, ne s'arrête jamais.
-f Ne fork pas, ne lance pas en tâche de fond

Variables d'environnement

LVM_LVMETAD_PIDFILE Chemin du fichier pid.
LVM_LVMETAD_SOCKET Chemin du socket.
^
28 juin 2016

htmlpdflatexmanmd




lvmlockctl

lvmlockctl

Contrôle pour lvmlockd

OPTIONS

--quit|-q Terminer lvmlockd
--info|-i AFfiche les informations d'état de lock depuis lvmlockd
--dump|-d Affiche le tampon de log de lvmlockd
--wait|-w 0|1 Option d'attente pour les autres commandes
--force|-f 0|1 Option force pour les autres commandes
--kill|-k ‹vgname› Tue l'accès au VG quand sanlock ne peut pas renouveler le bail
--drop|-r ‹vgname› Efface les locks pour le VG quand il n'est plus utilisé après --kill
--gl-enable|-E ‹vgname› Active le lock global dans le VG sanlock
--gl-disable|-D ‹vgname› Désactive le lock global dans le VG sanlock
--stop-lockspaces|-S Stop tous les lockspaces
^
28 juin 2016

htmlpdflatexmanmd




lvmlockd

lvmlockd

Service de lock LVM

   Les commandes LVM utilisent lvmlockd pour coordonner l'accès au stockage partagé. Quand LVM est utilisé sur des périphériques partagés par plusieurs hôtes, les locks vont:

- Coordonner la lecture/écriture dus métadonnées LVM
- Valider le cache des métadonnées
- Empêcher l'activation concurrente des volumes logiques

   lvmlockd utilise un gestionnaire de lock externe, les options sont:

sanlock Place les locks sur le disque dans le stockage LVM
dlm Utilise la communication réseaux et un gestionnaire de cluster

OPTIONS

--test|-T Mode test
--foreground|-f Ne lance pas en tâche de fond
--daemon-debug|-D Ne fork pas et affiche le débug sur stdout
--pid-file|-p path Spécifie le fichier PID
--socket-path|-s path Définis le chemin du socket
--syslog-priority|-S err|warning|debug Spécifie la priorité syslog
--gl-type|-g sanlock|dlm Définis le type de lock global
--host-id|-i num Définis l'id hôte pour le sanlock local
--host-id-file|-F path Un fichier contenant le sanlock local host_id
--sanlock-timeout|-o seconds Remplace le timeout d'E/S sanlock par défaut
--adopt|-A 0|1 récupère les locks d'une instance précédente de lvmlockd

Utilisation

   En utilisant LVM avec lvmlockd la première fois, il est nécessaire d'effectuer les étapes suivantes:

1. Choisir un gestionnaire de lock

        dlm Si dlm (ou corosync) est déjà utilisé par un autre logiciel cluster, sélectionner dlm. dlm utilise corosync qui nécessite une configuration additionnelle au delà du périmètre de ce document.
        sanlock sanlock ne dépend pas d'un logiciel de clustering

2. Configurer les hôtes pour utiliser lvmlockd Sur tous les hôtes où lvmlockd fonctionne, configurer lvm.conf:


       
locking_type = 1
use_lvmlockd = 1
# avec sanlock, assigner un host_id unique (de 1 à 2000) dans /etc/lvm/lvmlocal.conf local/host_id

3. Démarrer lvmlockd Utiliser un fichier d'init ou simplement lancer lvmlockd
4. Démarrer le gestionnaire de lock (sanlock) systemctl start wdmd sanlock ou (dlm) systemctl start corosync dlm
5. Créer un VG sur les périphériques partagés vgcreate --shared ‹vgname› ‹devices›. L'option shared définis le type de lock VG à sanlock ou dlm en fonctionne du gestionnaire utilisé.
6. Démarrer le VG sur tous les hôtes vgchange --lock-start. lvmlockd nécessite que les VG partagés soient démarrés avant qu'ils soient utilisés. Le lock manager démarre (joint) le lockspace du VG et peut prendre du temps.
7. Créer et activer les LV Les commandes lvcreate et lvchange sont utilisées pour créer et activer les LV dans un VG partagé. Un LV activé exclusivement sur un hôte ne peut pas être activé sur un autre. Quand plusieurs hôtes doivent utiliser le même LV simultannément, le LV peut être activé avec un lock partagé.

Démarrage et arrêt Une fois la configuration initiale, le démarrage et l'arrêt incluent les étapes suivantes. Elles sont effectuée manuellement ou en utilisant le gestionnaire de service système:

        - Démarrer lvmetad
        - Démarrer lvmlockd
        - Démarrer le lock manager
        - vgchange --lock-start
        - Activer les LV dans les VG partagés

La séquence d'arrêt est l'inverse:

        - Désactiver les LV dans les VG partagés
        - vgchange --lock-stop
        - Arrêter le gestionnaire de lock
        - Arrêter lvmlockd
        - Arrête lvmetad

Contrôle d'accès au VG

   Les termes suivants sont utilisés pour décrire les différentes formes de contrôle d'accès au VG.

   Un lockd VG est un VG partagé qui a un 'lock type' dlm ou sanlock. Il nécessite lvmlockd. Ces VG existent sur des stockages partagés qui sont visibles à plusieurs hôtes. Les commandes LVM utilisent lvmlockd pour effectuer le lock pour ces LV quand ils sont utilisés.

   Si le gestionnaire de lock pour le type de lock n'est pas disponible (par ex non démarré est échoue), lvmlockd n'est pas capable d'acquérir les locks pour les commandes LVM. Les commandes LVM qui lisent uniquement le VG vont généralement être autorisé à continuer sans locks dans ce cas. Les commandes pour modifier ou activer le VG vont échouer.

   Un local VG est utilisé par un simple hôte. Il n'a pas de type de lock ou un type 'none'. Les commandes LVM et lvmlockd n'effectuent pas de lock pour ces VG. Un VG local existe typiquement sur les périphériques locaux et ne peuvent pas être utilisés par différents hôtes.

   Si un VG local existe sur des périphériques partagés, il devrait être possédé par un simple hôte en ayant son system_id définis. Seul l'hôte avec un system_il correspondant peut utiliser le VG local. Un VG sans type de lock et sans system_id devrait être exclus de tous sauf un hôte en utilisant les filtres lvm.conf. Sans protection, un VG local sur un périphérique partagé peut facilement être endommagé ou détruit.

   Un VG clvm est un VG sur un stockage partagé qui nécessite clvmd pour le clustering.

VG lockés sur les hôtes n'utilisant pas lvmlockd

   Seul les hôtes qui utilisent les VG lockd devraient être configurés pour lancer lvmlockd. Cependant, les périphériques partagés utilisés par les VG lockd peuvent être visible aux hôte n'utilisant par lvmlockd. D'un hôte n'utilisant pas lvmlockd, les VG lockd sont ignorés de la même manière que les VG étranger. L'option --shared pour le reporting et les commandes d'affichage affichent les VG lockd sur un hôte n'utilisant pas lvmlockd, tout comme --foreign affiche les VG étranger.

Comparaison vgcreate

   Le type de contrôle d'accès VG est spécifié dans la commande vgcreate pour toutes les options vgcreate

vgcreate ‹vgname› ‹devices› Créé un VG local avec le system_id local quand lvmlockd et clvm ne sont pas configurés
Créé un VG local avec le system_id local quand lvmlockd est configuré
Créé un VG clvm quand clvm est configuré
vgcreate --shared ‹vgname› ‹devices› Nécessite que lvmlockd soit configuré est fonctionnel
Créé un VG lockd avec le type de lock sanlock|dlm en fonction du gestionnaire de lock courant
Les commandes LVM nécessitent des locks de lvmlockd pour utiliser le VG
lvmlockd obtient les locks depuis le gestionnaire de lock sélectionné
vgcreate -c|--clustered y ‹vgname› ‹devices› Nécessite que clvm soit configuré et fonctionnel
Créé un VG clvm avec le flag clustered
Les commandes LVM réclament les lockd à clvmd pour utiliser le VG

Créer le premier VG sanlock

   Créer le premier VG sanlock n'est pas protégé par le locking et nécessite une attention particulière. les sanlock existent dans le VG, donc ils ne sont pas disponible tant que le VG n'existe pas. Le premier sanlock VG contient le lock global.

- Le premier vgcreate doit avoir le chemin vers un périphérique qui n'a pas été initialisé avec pvcreate. L'initialisation pvcreate nécessite le lock global, qui ne sera pas disponible tant que le premier sanlock VG n'est pas crée
- En lançant vgcreate pour le premier sanlock VG, s'assurer que le périphérique utilisé n'est pas utilisé par une autre commande LVM. L'allocation de périphériques partagés est généralement protégé par le lock global, mais cela ne peut pas être fait pour le premier sanlock VG qui va maintenir le lock global
- En lançant vgcreate pour le premier sanlock VG, s'assurer que le nom du VG n'est pas utilisé par une autre commande LVM. L'unicité des noms des VG est généralement assurée par le lock global.
- Parce que le premier sanlock VG contient le lock global, ce VG doit être accessible à tous les hôtes qui utilisent les VG partagés avec sanlock. Tous les hôtes doivent utiliser le lock global depuis le premier VG sanlock.

Utiliser les VG lockd

   Il y a quelques considération spéciales en utilisant les VG lockd. Quand use_lvmlockd est activé dans lvm.conf, puis le premier VG lockd est créé, il n'existe pas de lock global. Dans cet état initial, les commandes LVM tentent et échouent à acquérir le lock global, produisant une alert, et certaines commande sont désactivée. Une fois le premier VG lockd créé, le lock global sera disponible, et LVM sera pleinement opérationnel.

   Quand un nouveau VG lockd est créé, son espace de lock est automatiquement démarré sur l'hôte qui l'a créé. Les autres hôte doivent lancer vgchange --lock-start pour démarrer le nouveau VG avant de pouvoir l'utiliser.

   Depuis la commande vgs, les VG lockd sont indiqués par 's' dans le champ attr. Le type de lock et les arguments de lock peuvent être affichés avec vgs -o+locktype,lockargs

   Les VG lockd doivent être démarrés et stoppé, , à la différence d'autres types de VG.

   vgremove d'un VG lockd échoue si d'autres hôte ont le VG démarré. Lance vgchange --lock-stop ‹vgname› sur tous les autres hôtes avant un vgremove.

Démarrer et stopper les VG

   Démarrer un VG lockd (vgchange --lock-start) indique au gestionnaire de lock de démarrer (joindre) le lockspace pour le VG sur l'hôte où il est lancé. Les locks créés pour le VG sont disponibles pour les commandes LVM sur l'hôte. Avant qu'un VG soit démarré, seu les commandes LVM qui lisent/affichent le VG sont autorisés à continuer sans locks. En utilisant le type de lock sanlock, démarrer un VG peut prendre du temps.

   Stopper un VG lockd (vgchange --lock-stop) indique au gestionnaire de stopper (quitter) le lockspace pour le VG sur l'hôte où il est lancé. Un VG ne peut pas être stoppé pendant qu'il a des LV actifs.

   Un VG lockd peut être démarré une fois que les points suivants soient vrai:

- lvmlockd est en cours de fonctionnement
- le gestionnaire de lock est en cours de fonctionnement
- Le VG est visible au système

Un VG lockd peut être stoppé si tous les LV sont désactivés. Tous les VG lockd peuvent être démarrés/stoppé en utilisant:
vgchange --lock-start
vgchange --lock-stop
Les VG individuels peuvent être démarrés/stoppé en utilisant:
vgchange --lock-start ‹vgname› ...
vgchange --lock-stop ‹vgname› ...
Pour que vgchange n'attende pas que le démarrage soit complété:
vgchange --lock-start --lock-opt nowait ...
lvmlockd peut être appélé directement pour stopper tous les lockspaces
lvmlockctl --stop-lockspaces

   Pour démarrer seulement les VG lockd sélectionnés, utiliser lvm.conf activation/lock_start_list. Quand défini, seul les VG nommés dans cette liste sont démarrés par vgchange. Si la liste n'est pas définie, tous les VG lockd visibles sont démarrés.

Démarrage et activation automatique

Les scripts ou programmes dans l'hôte qui démarrent automatiquement les VG utilisent l'option auto pour indiquer que la commande est lancée automatiquement par le système:
vgchange --lock-start --lock-opt auto [‹vgname› ...]

   Sans configuration additionnelle, l'option auto n'a pas d'effet; tous les VG sont démarrés sauf restreint par lock_start_list

   Cependant, quand activation/auto_lock_start_list dans lvm.conf est définis, la commande de démarrage auto effectue une phase de filtrage supplémentaire pour tous les VG démarrés, en testant chaque nom de VG avec la liste auto_lock_start_list. Cette directive définis les VG lockd qui seront démarré par la commande auto. Les VG lockd visible non incus dans la liste sont ignorés par la commande de démarrage auto. Si la liste est indéfinis, tous les noms de VG passent ce filtre.

   auto_lock_start_list permet à un utilisateur de sélectionner certains VG lockd qui devraient être démarrés automatiquement par le système. Pour utiliser l'auto activation des LV lockd, (voir auto_activation_volume_list), le démarrage automatique les VG lockd correspondants sont nécessaire.

Lock interne

   Pour optimiser l'utilisation de LVM avec lvmlockd, il y'a 3 types de locks:

GL lock

   Le lock global est associé avec les informations globales. qui ne sont pas isolés à un seul VG. Cela inclus l'espace de nom VG global, le jeu de périphérique non-utilisés et les PV orphelins et les propriétés des PV orphelins. Le lock global est utilisé en mode partagé par les commandes qui lisent cette information, ou en mode exclusif par les commandes que la change.

   La commande vgs acquière le lock global en mode partagé parce qu'il reporte la liste de tous les noms des VG.

   vgcreate acquière le lock global en mode exclusif parce qu'il créé un nouveau nom VG, et prend un PV de la liste des PV non utilisés

   Quand une commande LVM est donnée avec un tag, ou utilise select, il doit lire tous les VG pour correspondre au tag ou à la sélection, qui nécessite d'acquérir le lock global.

VG lock

   Un lock VG est associé avec chaque VG. Il est obtenu en mode partagé pour lire le VG et en mode exclusif pour le changer. Ce lock sérialise l'accès au VG avec toutes les autres commandes LVM accédant au VG depuis tous les hôtes.

   La commande vgs n'acquière le lock global que pour lire la liste de tous les noms VG, mais acquière le lock VG pour chaque VG avant de le lire.

lock LV

   Un lock LV est acquis avant que le LV soit activé, et est relâché après que le LV soit désactivé. Si le lock LV ne peut pas être acquis, le LV n'est pas activé. Les locks LV sont persistant et restent en place une fois l'activation faite. Les locks GL et VG sont transitoires et sont maintenus seulement pendant une commande LVM.

Retentatives de lock

   Si une requête pour un lock GL ou VG échoue à cause d'un conflit de lock avec un autre hôte, lvmlockd retente automatiquement pendant un cour lapse de temps avant de retourner une erreur à la commande LVM. Si ces retentatives sont insuffisantes, la commande LVM va retenter toute la demande de lock un nombre de fois spécifié par global/lvmlockd_retries avant d'échouer. Si une requête pour un lock LV échoue à cause d'un conflit de lock, la commande échoue immédiatemen.

Gérer le lock global dans les VG sanlock

   Le lock global existe dans un des VG sanlock. Le premier VG sanlock créé va contenir le lock global. Les VG sanlock suivant vont chacun contenir des locks global désactivés qui peuvent être activés ultérieurement si nécessaire.

   Le VG contenant le lock global doit être visible à tous les hôtes utilisant les VG sanlock. Cela peut être une raison de créer un petit VG sanlock, visible à tous les hôte, et dédié à maintenir ce lock global. Bien que non requis, cette stratégie peut éviter les problème si des VG sont déplacés ou supprimés.

   La commande vgcreate acquière typiquement le lock global, mais dans le cas du premier VG sanlock, il n'y a pas de lock global à acquérir tant que le premier vgcreate n'est pas complété. Donc, créer le premier VG sanlock est un cas spécial qui ignore le lock global.

   vgcreate pour un VG sanlock détermine qu'il est le premier à exister si aucun autre VG sanlock n'est visible. Il est possible que d'autre VG sanlock existent mais ne sont pas visible à l'hôte que lance vgcreate. Dans ce cas, vgcreate créé un nouveau VG sanlock avec le lock global activé. Quand l'autre VG sanlock avec le lock global apparaît, lvmlockd va voir plus d'un VG avec un lock global activé, et les commandes LVM vont reporter qu'il y a des locks global dupliqués.

Si la situation se produit où plus d'un VG sanlock contient un lock global, le lock global devrait être désactivé manuellement dans tous sauf un avec la commande:
lvmlockctl --gl-disable ‹vgname›

Un problème opposé peut se produire si le VG maintenant le lock global est supprimé. Dans ce cas, aucun lock global n'existe, et les commande LVM échouent à l'acquérir. Dans ce cas, le lock global doit être manuellement activé dans un des VG sanlock restant avec la commande:
lvmlockctl --gl-enable ‹vgname›

   Un petit VG sanlock dédié pour maintenir le lock global peut éviter ce cas.

LV lvmlock interne

   Un VG sanlock contient un LV caché appelé lvmlock qui maintient les locks sanlock. vgreduce ne peut pas supprimer le PV maintenant le LV lvmlock. Pour supprimer ce PV, changer le type de lock VG à none, lancer vgreduce, puis changer le type lock VG à sanlock. Similairement, pvmove ne peut pas être utilisé dans un PV utilisé par le LV lvmlock. Pour placer le LV lvmlock dans un périphérique spécifique, créer le VG avec seulement ce périphérique, puis utiliser vgextend pour ajouter d'autres périphériques.

LV partagés

   Quand un LV est utilisé en concurrence par plusieurs hôtes, le LV peut être activé sur plusieurs hôtes en utilisant un lock partagé. Pour activer le LV avec un lock partagé: lvchange -asy vg/lv

   Avec lvmlockd, une mode d'activation non-spécifié est toujours exclusif, par exemple, -ay vaut -aey.

   Si le type LV ne permet pas au LV d'être utilisé en concurrence par plusieurs hôtes, le lock d'activation partagé n'est pas permis et la commande lvchange va reporter une erreur. Les types LV qui ne peuvent pas être utilisés en concurrence depuis plusieurs hôtes sont les thin, cache, raid, mirror, et snapshot.

   lvextend sur un LV avec des locks partagé n'est pas encore permis. Le LV doit être désactivé, ou activé exclusivement pour lancer lvextend.

Récupérer les locks sanlock des PV perdus

   L'approche générale est de changer le type de lock VG à none, puis remettre à sanlock. Cela recréé le LV lvmlock interne et les locks nécessaires. D'autres étapes peuvent être nécessaire pour gérer les PV manquants.

Erreurs système de lock

lvmlockd Si lvmlockd échoue ou est terminé pendant qu'il maintient les lock, les locks sont orphelins dans le gestionnaire de lock. lvmlockd peut être redémarré avec une options pour adopter les locks dans le gestionnaire de lock qui les maintenait depuis une instance précédente.
dlm/corosync Si dlm ou corosync échoue, le système de clustering va isoler l'hôte en utilisant une méthode configuré dans le cluster. Les commandes LVM sur les autres hôtes ne pourront pas acquérir de lock tant que le procéssus de récupération n'est pas terminé.

Erreur de stockage sanlock

   Si le PV sous un LV lvmlock dans un VG sanlock est déconnecté, ne répond pas ou est trop lent, sanlock ne peut pas renouveler le bail pour les locks des VG. Après un certain temps, le bail expire, et les locks que l'hôte possède dans le VG peuvent être acquis par d'autres hôtes. Le VG doit être désactivé sur l'hôte avec le bail expiré avant que d'autres hôtes puissent acquérir les locks.

   Quand le service sanlock détecte que le bail du stockage est perdu, il lance la commande lvmlockctl --kill ‹vgname›. Cette commande émet un message syslog indiquant que le bail du stockage est perdu pour le VG et les LV doivent être immédiatement désactivés.

   Si aucun LV n'est actif dans le VG, le lockspace avec un bail expiré est supprimé, et les erreurs sont reportés en tantant d'utiliser le VG. Utiliser lvmlockctl --drop pour effacer le lockspace gelé de lvmlockd.

   Si le VG a des LV actifs quand le lock est perdu, les LV doivent être rapidement désactivés avant que le bail lockspace n'expire. Une fois tous les LV désactivés, lvmlockctl --drop ‹vgname› efface le lockspace ede lvmlockd. Si tous les LV dans le VG ne sont pas désactivés dans les 40 secondes, sanlock réinitialise l'hôte en utilisant le watchdog local. La réinitialisation machine est effectivement une forme sévère de désactivation les LV avant de pouvoir être activés dans d'autres hôtes.

   Dans le future, lvmlockctl kill pourra tenter automatiquement de forcer la désactivation des LV avant le que bail n'expire.

Erreur du service sanlock

   Si le service sanlock échoue pou quitte alors que le lockspace est démarré, le watchdog local réinitialise l'hôte. C'est nécessaire pour protéger les ressources d'application qui dépendent des bails sanlock.

Changer le nom du cluster dlm

   Quand un VG dlm est créé, le nom du cluster est sauvegardé dans les métadonnées du VG. Pour utiliser le VG, un hôte doit être dans le cluster dlm nommé. Si le nom change, ou le VG est déplacé dans un nouveau cluster, le nom du cluster dlm sauvegardé dans le VG doit également être changé.

Pour voir le nom du cluster dlm dans le VG, utiliser
vgs -o+locktype,lockargs ‹vgname›
Pour changer le nom du cluster dlm dans le VG:

        - stopper le VG sur tous les hôte
        vgchange --lock-stop ‹vgname›
        - Changer le type de lock VG à none
        vgchange --lock-type none ‹vgname›
        - Changer le nom du cluster dlm sur l'hôte ou déplacer le VG dans le nouveau cluster. Le nouveau cluster dlm doit être actif sur l'hôte
        cat /sys/kernel/config/dlm/cluster/cluster_name
        - Changer le type de lock VG à dlm qui définis le nouveau nom du cluster
        vgchange --lock-type dlm ‹vgname›
        Démarrér le VG sur les hôte qui l'utilisent
        vgchange --lock-start ‹vgname›

   Pour changer le nom du cluster dlm dans le VG quand le nom du cluster dlm a déjà changé, ou le VG a déjà été déplacé dans un autre cluster:

        - S'assurer que le VG n'est pas utilisé par un hôte
        - Le nouveau cluster dlm doit être actif
        cat /sys/kernel/config/dlm/cluster/cluster_name
        - Changer le type de lock VG à none
        vgchange --lock-type none --force ‹vgname›
        - Changer le type de lock à dlm
        vgchange --lock-type dlm ‹vgname›
        Démarrer le VG sur les hôtes qui l'utilisent
        vgchange --lock-start ‹vgname›

Changer un VG local en VG lockd

   Tous les LV doivent être inactifs pour changer le type de lock. lvmlockd doit être configuré et en cours de fonctionnement.

Changer un VG local en VG lockd avec la commande
vgchange --lock-type sanlock|dlm ‹vgname›
Démarrér le VG sur les hôte qui l'utilisent
vgchange --lock-start ‹vgname›

Changer un VG lockd en VG local

   Stopper le VG lockd sur tous les hôtes, puis lancer
   Pour changer un VG d'un type lockd à un autre, le changer d'abord en un VG local, puis dans le nouveau type

Changer un VG clvm en VG lockd

Tous les LV doivent être inactif pour changer le type de lock. Changer d'abord le VG clvm en VG local. Dans un cluster clvm en cours de fonctionnement, changer un VG clvm en VG local avec
vgchange -cn ‹vgname›
Si le cluster clvm n'est plus en cours de fonctionnement sur aucun nœud, des options supplémentaires peuvent être utilisées pour forcer le VG local
vgchange --config 'global/locking_type=0 global/use_lvmlockd=0' -cn ‹vgname›
Une fois le VG en local, suivre les étapes dans changer un VG local en un VG lockd.

Limites des VG lockd

   Listes de ce qui ne fonctionne pas encore dans les VG lockd

        - Créer un nouveau pool thin et un nouveau lv thin en une seule commande
        - Utiliser lvcreate pour créer des pools cache ou des LV cache (utiliser lvconvert)
        - Utiliser des origines externes pour les LV thin
        - Spliter les mirroirs est snapshots des LV
        - vgsplit
        - vgmerge
        - redimensionner un LV qui est actif dans le mode partagé sur plusieurs hôtes.

Changement lvmlockd depuis clvmd

   Bien que lvmlockd et clvmd sont des système entièrement différents, l'utilisation des commande LVM restent similaires. Les différences sont plus notables en utilisant l'option sanlock de lvmlockd. La différence d'utilisation visible entre les VG lockd avec lvmlockd et les VG clvm avec clvmd sont:

        - lvm.conf doit être configuré pour utiliser soit lvmvlockd (use_lvmlockd=1) soit clvmd (locking_type=3), mais pas les 2
        - vgcreate --shared créé un VG lockd, et vgcreate --clustered y créé un VG clvm
        - lvmlockd ajoute l'option pour utiliser sanlock pour le locking, évitant le besoin d'un cluster réseau.
        - lvmlockd utilise le mode d'activation exclusif par défaut quand le mode l'activation n'est pas spécifié. -ay signifie -aey
        - Les commandes lvmlockd s'appliquent toujours à l'hôte local, et n'a pas d'effet sur les hôte distants
        - lvmlockd fonctionne avec les pools thin et cache
        - lvmlockd fonctionne avec lvmetad
        - lvmlockd sauve le nom du cluster dans le VG lockd utilisant dlm
        - lvmlockd nécessite de démarrer/stopper les VG lockd avec vgchange --lock-start et --lock-stop
        - vgremove d'un VG sanlock peut échouer en indiquant que tous les hôtes ne sont pas stoppés dans le lockspace du VG
        - vgreduce ou pvmove d'un PV dans un VG sanlock échoue s'il maintient le LV lvmlock
        - lvmlockd utilise les retentatives lock au lieu de files d'attentes de lock
        - lvmlockd inclus des options de reporting VG lock_type et lock_args, et une options de reporting LV lock_args pour voir les champs de métadonnées correspondants
        - Les les commande vgs, le 6ème champ, "s" pour "shared" est affiché pour les VG lockd
        - Si lvmlockd échoue ou est terminé pendant qu'il est en cours d'utilisation, les locks restent, mais sont orphelins dans le gestionnaire de lock. lvmlockd peut être redémarré avec une option pour adopter les locks orphelins depuis une précédente instance de lvmlockd.
^
23 mai 2016

htmlpdflatexmanmd




lvmpolld

lvmpolld

Service lvm d'interrogation

   lvmpolld est un service de scrutin pour lvm. Le service reçoit des requêtes pour interroger les opérations déjà initialisée dans la commande lvm2. Les requêtes d'interrogation viennent de lvconvert, pvmove, lvchange ou vgchange.

   Le but de lvmpolld est de réduire le nombre de processus en tâche de fond par opération. Il élimine également la possibilité de terminer de manière non-solicitée les processus par des facteurs externes.

   lvmpolld est utilisé par lvm seulement si permis dans lvm.conf en spécifiant le paramètre global/use_lvmpolld.

OPTIONS

   Pour lancer le service dans un environnement de test, pidfile_path et socket_path doivent être changés.

-f, --foreground Ne fork pas, ne lance pas en tâche de fond
-l, --log {all|wire|debug} Sélectionne le type de message de log à générer. Les messages sont loggés par syslog.
-p, --pidfile chemin du fichier pid. défaut: /run/lvmpolld.pid
-s, --socket Chemin du fichier socket. Défaut: /run/lvm/lvmpolld.socket
-t, --timeout Le service s'arrête après le temps donné sans opération. à 0, ne quitte jamais
-B, --binary Chemin alternatif du binaire lvm.
--dump Contacte le service lvmpolld en cour de fonctionnement pour obtenir l'état complet et affiche les données au format brut.

Variables d'environnement

LVM_LVMPOLLD_PIDFILE Chemin du fichier pidfile
LVM_LVMPOLLD_SOCKET Chemin du fichier socket
^
06 juin 2016

htmlpdflatexmanmd




lvmsystemid

lvmsystemid

ID système LVM

   Les VG locaux peuvent exister sur des stockages partagés où ils sont visibles à plusieurs hôtes. Ces VG sont prévus pour être utilisé par une seule machine. Un system_id identifiant un hôte unique peut être assigné à un VG pour indiquer le propriétaire du VG. Ce propriétaire peut utiliser le VG normalement, et tous les autres hôtes vont l'ignorer.

   Le system id n'est pas une propriété dynamique, et peut seulement être changée dans des circonstances très limitées. Ces changements limités ne sont pas parfaitement reflétés via les hôtes. Une vue plus cohérente de stockage partagée nécessite d'utiliser un système de lock inter-hôte pour coordonner l'accès et mettre à jours les caches.

   Le system_id est une chaîne identifiant un hôte de manière unique. Il peut être définis manuellement ou automatiquement par lvm en utilisant un identifiant unique déjà disponible dans l'hôte, par exemple machine-id ou uname.

   Dans vgcreate, le system_id local est sauvé dans les métadonnées du VG. L'hôte local possède le nouveau VG, et les autres hôtes ne peuvent pas l'utiliser.

   Un VG sans system_id peut être utilisé par n'importe quel hôte. un foreign VG est un VG avec un system_id tel que vu par un hôte avec un system_id qui ne matche pas le system_id du VG.

   Les caractères de system_id valides sont les mêmes que les caractères valides pour un nom de VG. Si un system_id contient des caractères invalides, ils sont omis. Si un system_id dépasse la longueur maximale (128), il est tronqué.

Limitations et alertes

   pour bénéficier pleinement du system_id, tous les hôtes doivent avoir un system_id, et les VG également. Un VG sur un stockage partagé peut être endommagé ou détruit dans certains cas.

- Un VG sans system_id peut être utilisé sans restriction par tous les hôtes, même les hôtes qui ont un system_id. Pour vérifier qu'un VG a un system_id, utiliser vgs -o+systemid. Pour ajouter un system_id, utiliser vgchange --systemid
- 2 hôtes ne devraient pas avoir le même system_id.
- Les PV orphelins (ou les périphériques inutilisés) sur des stockages partagés sont complètement non-protégés par le systemid. Les commandes qui utilisent ces PV, tel que vgcreate ou vgextend, peut effectuer des opérations conflictuelles et corrompre les PV.

types d'accès VG

   Un VG local est prévu pour être utilisé par un simple hôte. Un VG partagé ou clusterisé est prévu pour être utilisé par plusieurs hôtes. Ils peuvent être distingués par:

non-restreint: un VG local qui n'a pas de system_id. Ce type de VG n'est pas protégé est accéssible à tous les hôtes
possédé: un VG local qui a un system_id, tel que vu par un hôte anay un system_id correspondant. Ce VG est accessible à l'hôte
Étranger: un VG local qui a un system_id, tel que vu par un hôte ayant un system_id qui ne correspond pas.
Exporté: un VG local qui a été exporté avec vgexport et n'a pas de system_id. Ce type de VG ne peut être accédé que par vgimport.
partagé: un VG partagé ou "lockd" a lock_type définis et pas de system_id. il est utilisé sur un stockage partagé pour plusieurs hôtes, uniquement via lvmlockd
clusterisé: Un VG clusterisé ou "clvm" a le flag clustered mis et pas de system_id. Il est utilisé sur un stockage partagé par plusieurs hôtes, en utilisant clvmd.

system_id_source Le system_id d'un hôte peut être définis de plusieurs manières. lvm.conf global/system_id_source définis la méthode utilisée pour trouver le system_id local:

        none lvm n'utilise pas de system_id
        machineid Le contenu de /etc/machine-id est utilisé comme id système
        uname La chaîne utsname.nodename de uname(2) est utilisé comme system_id.
        lvmlocal Définis dans lvmlocal.conf local/system_id
        file définis dans un fichier spécifié par lvm.conf global/system_id_file

   Changer system_id_source change le system_id, ce qui peut empêcher l'utilisation de VG. Si un system_id_source autre que none échoue à la résolution du system_id, l'hôte sera autorisé à accéder aux VG sans system_id, mais ne sera pas autorisé à accéder aux VG avec un system_id.

extra_system_ids

   Dans certains cas, l'hôte qui lance la commande assigne son propre system_id au nouveau VG. Pour le remplacer par un autre system_id, utiliser: vgcreate --systemid ‹SystemID› ‹VG› ‹Devices›. Si l'argument de --systemid est une chaîne vide, le VG est créé sans system_id.

Rapport/affichage

   Le system_id d'un VG est affiché avec l'option de repporting systemid. Les commandes de rapport/affichage ignorent les VG étrangés par défaut. Pour afficher ces VG, l'option --foreign peut être utilisé. Cela implique que la commande lise les VG sur les disques et non via lvmetad.

vgexport/vgimport

   vgexport efface le system_id. Les autres hôtes continuent à voir le VG nouvellement exporté comme étrangé à cause du caching local (quand lvmetad est utilisé). Mettre à jours manuellement le cache avec pvscan --cache pour reconnaître le nouveau VG exporté.

   vgimport définis le system_id. vgimport scanne automatiquement les nouveaux VG exportés.

vgchange

Un hôte peut changer le system_id de ses propres VG, mais la commande nécessite confirmation du fait que l'hôte perd l'accès à ces VG
vgchange --systemid SystemID VG

   Le system_id peut être supprimé d'un VG en spécifiant une chaîne vide comme nouveau system_id. Un hôte ne peut pas changer directement le system_id d'un VG étranger. Pour déplacer un VG d'un hôte à un autre, vgexport et vgimport doivent être utilisés. Pour devenir propriétaire d'un VG étranger, un hôte peut ajouter le system_id étranger à sa liste extra_system_ids, changer le system_id de ce VG, puis supprimer le system_id de sa extra_system_ids.

VG partagés

   Un VG partagé/lockd n'a pas de system_id, permettant à plusieurs hôte de l'utiliser via lvmlockd. Changer un VG en un type lockd efface le system_id.

VG clusterisés

   Un VG clusterisé/clvm n'a pas de system_id, permettant à plusieurs hôte de l'utiliser via clvmd. Changer un VG en type clustered efface le system_id existant. Changer le VG clustered en non-clustered définis le system_id de l'hôte qui a lancé la commande vgchange.

creation_host

   dans vgcreate, le champ de métadonnées VG creation_host est définis par défaut à uname de l'hôte. Ce champ ne peut pas être changé, et n'est pas utilisé pour contrôler l'accès. Quand system_id_source est "uname", system_id et creation_host sont les même.

Orphelins

   Les VG orphelins sont des périphériques non-utilisé. À cause de celà, il ne sont pas protégés par un system_id, et tous les hôtes peuvent les utiliser. La coordination des changements des changements en VG orphelins est hors du périmètre du system_id.

   Les effets sont spécialement évidents quand lvm utilise lvmetad. Par exemple, si plusieurs hôte voient un VG orphelin, et un hôte créé un VG en utilisant l'orphelin, les autres hôtes continuent de le voir orphelin. Rien n'empêche les autres hôte d'utiliser ce PV et le corrompre. Si les autres hôte lancent une commande de rescan, et mettent à jours lvmetad, ils le reconnaîtront.
^
22 mai 2016

htmlpdflatexmanmd




lvmthin

lvmthin

Provisionning léger lvm

   Les blocks dans un volume logique standard sont alloués quand le LV est créé, mais les blocks dans un provisionning léger sont alloués quand ils sont écris. À cause de celà, un LV thin provisioned a une taille virtuelle, et peut être plus grand que l'espace physique disponible. La quantité de stockage physique fournie pour les LV thin provisioned peut être augmentée ultérieurement en cas de besoin.

   Les blocks dans un LV standard sont alloués (durant la création) dans le VG, mais les blocks dans un LV thin sont alloués (durant l'utilisation) depuis un "thin pool LV" spécial. Ce pool contient des blocks de stockage physique, et les blocks dans les LV thin référencent simplement les blocks dans le pool.

   Un thin pool LV doit être créé avant que les LV thin puissent y être créés. Un thin pool LV est créé en combinant 2 LV standard: Un LV de données qui maintient les blocks pour les LV thin, et un LV de métadonnées, qui maintient les blocks de données associés avec les LV thin.

   Les snapshots de LV thin sont inefficaces parce que les blocks de données communs à un LV thin et un de ses snapshots sont partagés. Les snapshots peuvent être plus de LV thin ou d'autre snapshots thin. Les blocks communs à des snapshots récursifs sont également partagés dans le thin pool. Il n'y a pas de limite ou de dégradation des séquences de snapshots.

   Vu que les LV thin ou les LV snapshot y sont écris, ils consomment des blocks de données dans le pool. À mesure que les blocks de données diminuent dans le pool, il peut être nécessaire d'en fournir. Cela peut être en étandant le pool. Supprimer les LV thin ou les snapshots du pool peut également libérer des blocks dans le pool. Cependant, supprimer les LV n'est pas toujours une manière efficace de libérer de l'espace parce que la quantité est limité au nombre de blocks non partagés avec d'autres LV dans le pool.

   L'allocation de block incrémental de pools thin peut causer les LV à devenir fragmentés. Les LV standard évitent généralement en allouant tous les blocks en une fois durant la création.

Termes Thin

ThinDataLV Grand LV créé dans un VG, utilisé par le pool thin pour stocker les blocks ThinLV
ThinMetaLV Petit LV créé dans un VG, utilisé pour suivre l'utilisation des blocks de données
ThinPoolLV Combinaison de ThinDataLV et ThinMetaLV, contenant les ThinLV et les SnapLV
ThinLV Créé depuis le ThinPoolLV, apparaît blanc après la création
SnapLV Snapshot créé depuis le ThinPoolLV, apparaît comme un snapshot d'un autre LV après la création

Utilisation Thin

   La méthode première pour utiliser le provisionning thin est:

1. Créer ThinDataLV Créer un LV qui va maintenir les données du pool thin
lvcreate -n pool0 -L 10G vg0
2. Créer ThinMetaLV Créer un LV qui va maintenir les métadonnées
lvcreate -n pool0meta -L 1G vg0
3. Créer le ThinPoolLV Combiner les données et métadonnées en un LV pool
lvconvert --type thin-pool --poolmetadata vg0/pool0meta vg0/pool0
4. Créer un ThinLV Créer un nouveau LV thin depuis le pool. Ce LV est créé avec une taille virtuelle
lvcreate -n thin1 -V 1T --thinpool vg0/pool0
lvcreate -n thin2 -V 1T --thinpool vg0/pool0
5. Créer un SnapLV Créer des snapshots d'un ThinLV ou SnapLV existant. Ne pas spécifier -L, --size pour créer un snapshot.
lvcreate -n thin1s1 -s vg0/thin1
lvcreate -n thin1s2 -s vg/thin1
lvcreate -n thin1s1s1 -s vg/thin1s1
6. Activer un SnapLV Les snapshots thin sont créés avec le flag "activation skip", indiqué par l'attribut "k". Utiliser -K avec lvchange ou vgchange pour activer les snapshots avec l'attribut "k"
lvchange -ay -K vg0/thin1s1

Syntaxe alternative pour spécifier le type thin-pool

La syntaxe pour créer un pool est:
lvconvert --type -thin-pool --poolmetadata VG/ThinMetaLV VG/ThinDataLV
Un LV existant est convertis en un pool thin en changeant son type en thin-pool. Une syntaxe alternative peut être utilisée pour la même opération:
lvconvert --thinpool VG/ThinDataLV --poolmetadata VG/ThinMetaLV

   Le type thin-pool est déduit par lvm; l'option --thinpool n'est pas un alias pour --type thin-pool. L'utilisation de l'option --thinpool ici est différente de l'utilisation de l'option --thinpool en créant un LV thin, où il spécifie le pool dans lequel le LV thin est créé.

Automatic pool metadata LV

Un LV thin de données peut être convertis en un LV pool thin sans spécifier de LV metadata. LVM créé automatiquement un LV metadata dans le même VG
lvcreate -n pool0 -L 10G vg0
lvconvert --type thin-pool vg0/pool0

Spécifier des périphériques pour les LV de données et de métadonnées

Les LV de données et de métadonnées dans un thin pool sont mieux créés sur des périphériques physiques séparés. Pour cela, spécifie les nom de périphérique à la fin de la ligne lvcreate. Cela peu être utile pour utiliser des périphériques rapides pour les métadonnées
lvcreate -n pool0 -L 10G vg0 /dev/sdA
lvcreate -n pool0meta -L 1G vg0 /dev/sdB
lvconvert --type thin-pool --poolmetadata vg0/pool0meta vg0/pool0

Tolérance aux panne en utilisant RAID

Pour la tolérance aux panne, utiliser un raid pour le pool de données et de métadonnées. C'est recommandé pour les métadonnées
lvcreate --type raid1 -m 1 -n pool0 -L 10G vg0 /dev/sdA /dev/sdB
lvcreate --type raid1 -m 1 -n pool0meta -L 1G vg0 /dev/sdC /dev/sdD
lvconvert --type thin-pool --poolmetadata vg0/pool0meta vg0/pool0

LV metadata spare

La première fois qu'un LV pool est créé, lvm crée un lv metadata space dans le VG. Ce comportement peut être contrôlé avec l'option --poolmetadataspare y|n.

   Pour créer le LV pmspare (pool metadata spare), lvm crée d'abord un LV avec un nom par défaut, par ex lvol0, puis le convertit en un LV caché avec le suffix _pmspare, par ex, lvol0_pmspare. Un pmspare est conservé dans un VG à utiliser pour tout pool thin. Le pmspare LV ne peut pas être créé explicitement, mais peut être supprimé explicitement.

Exemple

lvcreate -n pool0 -L 10G vg0
lvcreate -n pool0meta -L 1G vg0
lvconvert --type thin-pool --poolmetadata vg0/pool0meta vg0/pool0

Vérification et réparation des métadonnées

Si un thin pool metadata est endommagé, il peut être réparé. Vérifier et réparer un thin pool metadata est analogue à lancer fsck sur un système de fichier.

Quand un thin pool LV est activé, lvm lance la commande thin_check pour vérifier les métadonnées dans le LV de métadonnées du pool.

lvm.conf thin_check_executable peut être définis avec une chaîne vide ("") pour désactiver l'étape thin_check. Ce n'est pas recommandé.
lvm.conf thin_check_options Contrôle les options de commande utilisées pour la commande thin_check

   Si la commande thin_check trouve un problème avec les métadonnées, le LV pool n'est pas activé, et les métadonnées doivent être réparées.

Les commandes de réparation simple ne réussisent pas toujours. La réparation avancée peut nécessiter d'éditer les métadonnée du pool thin et les métadonnées lvm.
lvconvert --repair VG/ThinPoolLV

   La réparation effectue les étapes suivantes:

1. Créer une nouvelle copie réparée des métadonnées lvconvert lance la commande thin_repair pour lire les métadonnées endommagées dans le LV de métadonnées existant, et écrit une nouvelle copie réparée dans le LV pmspare du VG.
2. Remplacer le thin pool metadata LV Si l'étape 1 est réussie, le LV de métadonnées du pool thin est remplacé avec le LV pmspare contenant les métadonnées corrigées. L'ancien devient visible avec le nouveau nom ThinPoolLV_tmetaN (où N est 0, 1, ...).

   Si la réparation fonctionne, le LV pool thin et ses LV thin peuvent être activés, et le LV contenant les métadonnées du pool thin endommagé peut être supprimé. Il peut être utile de déplacer le nouveau LV de métadonnées vers un meilleur PV.

   Si la réparation ne fonctionne pas, le LV du pool thin et ses LV thin sont perdus.

   Si les métadonnées sont restaurées manuellement avec thin_repair directement, le LV de métadonnées du pool peuvent être échangé avec un autre LV contenant les nouvelles métadonnées:

Activation des snapshots thin

Quand un LV snapshot thin est créé, il a le flag "activation skip" par défaut. Ce flag est indiqué par l'attribut 'k' affiché par lvs
lvs vg/thin1s1

   Ce flag indique que le LV snapshot n'est pas activé par des commande d'activation normales. Ce comportement ne s'applique pas aux commandes de désactivation.

   Un LV snapshot avec l'attribut 'k' peut être activé en utilisant -K (ou --ignoreactivationskip) en plus de l'option standard -ay (ou --activate y)

Commande pour activer un LV snapshot thin:
lvchange -ay -K VG/SnapLV

   Le flag persistant "activation skip" peut être désactivé durant lvcreate, ou ultérieurement avec lvchange en utilisant l'option -kn (ou --setactivationskip n). Il peut être activé avec -kv (ou --setactivationskip y).

   Quand le flag 'activation skip' est supprimé, les commandes d'activation normales vont activer le LV, et l'option -K n'est pas nécessaire

La commande pour créer un LV snapshot sans le flag:
lvcreate -kn -n SnapLV -s VG/ThinLV
Commande pour supprimer le flag d'un LV snapshot:
lvchange -kn VG/SnapLV

lvm.conf auto_set_activation_skip Contrôle le paramètre d'activation utilisé par lvcreate

Supprimer les LV pool thin, les LV thin et les snapshots

   Supprimer un LV thin et ses snapshots associés retourne les blocks utilisés au LV pool thin. Ces blocks sont réutilisés pour d'autres LV thin et snapshots.

   Supprimer un LV pool thin supprime le LV de données, et le LV de métadonnées et retourne l'espace au VG.

   La suppression de LV pool thin, LV thin et snapshots avec lvremove, ne peuvent pas être récupérés avec vgcfgrestore. vgcfgbackup ne récupère pas les métadonnées du pool.

Gérer manuellement l'espace libre d'un LV pool thin

   L'espace disponible dans le LV pool thin peut être affiché avec la commande lvs. L'espace libre peut être ajouté en étendant le LV pool thin.

Commande pour étendre l'espace du pool:
lvextend -L Size VG/ThinPoolLV

Exemple

Doubler l'espace physique d'un pool:
lvextend -L+10G vg0/pool0

   D'autres méthodes pour augmenter l'espace dans le pool inclus de supprimer un LV thin et des snapshots associés, ou lancer fstrim dans le système de fichier utilisant un LV thin.

Gérer manuellement l'espace de métadonnées d'un LV pool thin

   L'espace de métadonnées disponible dans un LV pool thin peut être affiché avec la commande lvs -o+metadata_percent

Commande pour étendre l'espace de métadonées du pool:
lvextend --poolmetadatasize Size VG/ThinPoolLV

Utiliser fstrim pour augmenter l'espace libre dans un LV pool thin

   Supprimer des fichiers dans un système de fichier au dessus d'un LV thin ne rajoute pas généralement d'espace libre dans le pool. Lancer manuellement fstrim peut retourner de l'espace dans le pool qui a été utilisé par des fichier supprimés. fstrim ne fonctionne pas si le LV pool thin a le mode discards à ignore.

Exemple

   Un pool thin a 10G d'espace physique, et un LV thin qui a une taille virtuelle 100G. Écrire un fichier 1G dans le système de fichier réduit l'espace libre dans le pool thin de 10% et augmente l'utilisation virtuelle du système de fichier de 1%. Supprimer le fichier de 1G restore les 1% virtuel du système de fichier, me ne restaure pas les 10% physiques. la commande fstrim restore cet espace physique au pool thin.

Étendre automatiquement le LV pool thin

   Le service lvm dmeventd (lvm2-monitor) supervise l'utilisation de données des LV pool thin et les étends quand l'utilisation atteind un certain niveau. L'espace libre nécessaire doit exister dans le VG pour étendre les LV pool thin. Superviser et étendre les LV pool thin sont contrôlés indépendamment.

Supervision

   Quand un LV pool thin est activé, dmeventd va le superviser par défaut. La commande pour démarrer et stopper la supervision dmeventd d'un LV pool thin:
   Le status de supervision actuel peut être affiché avec la commande lvs -o+seg_monitor

autoextension

   dmeventd devrait être configuré pour étendre les LV pool thin avant que tout l'espace soit utilisé. Les alertes sont émises via syslog quand l'utilisation d'un pool thin atteind 80%, 85%, 90% et 95%. Le point auquel dmeventd étend un pool, et la quantité sont contrôlés avec 2 paramètres de configuration:

lvm.conf thin_pool_autoextend_threshold % qui défins quand le pool devrait être étendu. À 100 désactive l'extension automatique. La valeur minimum est 50.
lvm.conf thin_pool_autoextend_percent Définis la quantité d'espace à ajouter, en pourcentage de la taille courante.

Désactivation

   Il y a plusieurs manières où l'extension des pools thin peut être empêché.

- Si le service dmeventd ne fonctionne pas, aucun monitoring ou extension automatique ne va se produire
- Même quand dmeventd fonctionne, toute la supervision peut être désactivée avec le paramètre de monitoring dans lvm.conf
- Pour activer ou créer un LV pool thin sans interagir avec dmeventd, utiliser l'option --ignoremonitoring peut être utilisé.
- Définir thin_pool_autoextend_threshold à 100 désactive l'extension automatique.

Exemple

   Si thin_pool_autoextend_threshold vaut 70 et thin_pool_autoextend_percent vaut 20, quand un pool excède 70% d'utilisation, il est étendu de 20%. Pour un pool de 1G, en utilisant 700M cela déclenche une redimmensionnement à 1,2G. Quand l'utilisation excède 840M, le pool sera étendu à 1,44G, et ainsi de suite.

Épuisement de l'espace

   Proprement géré, l'espace de données des pool thin devraient être étendus avant que tout l'espace soit utilisé. Si l'espace est déjà épuisé, il peut être toutefois être étendus.

   Le comportement d'un pool thin plein est configurable avec l'option --errorwhenfull y|n de lvcreate ou lvchange. Cette option ne s'applique seulement pour les écritures.

La commande pour changer le comportement d'un pool thin complet:
lvchange --errorwhenfull {y|n} VG/ThinPoolLV

lvm.conf error_when_full Contrôle l'erreur dans le fichier de configuration

Le paramètre courant d'un LV pool thin peut être affiché avec
lvs -o+lv_when_full

   Le paramètre errorwhenfull n'affecte pas les paramètre de supervision et autoextension, et ces derniers n'affectent pas non plus le paramètre errorwhenfull. C'est seulement quand la supervision/autoextension ne sont pas effectifs que le pool thin devient plein et que le paramètre errorwhenfull est appliqué.

   Le défaut est 'n'. Les écritures des LV thin sont acceptés et mis en queue, dans l'attente d'espace disponible. Une fois l'espace étendu, les écritures en attente sont traitées.

   En attendant d'être étendus, le pool thin met les écriture en queue pour 60 secondes (le défaut). Si l'espace n'a pas été étendus après ce délai, les écritures en queue retournent une erreur à l'appelant, par ex le système de fichier. Cela peut résulter en une corruption du système de fichier pour les systèmes de fichier non-journalisés qui peut nécessiter fsck. Quand un pool thin retourne des erreurs d'écriture à un LV thin, un système de fichier est sujet à la perte de données utilisateur non-synchronisés.

   Le timeout de 60 secondes peut être changé ou désactivé avec l'option du module kernel dm-thin-pool no_space_timeout.
^
23 mai 2016

htmlpdflatexmanmd




lvm lvpoll

lvm lvpoll

Commande interne utilisée par lvmpolld pour compléter des opérations de volume logique

   lvpoll est utilisé par lvmpolld pour superviser et compléter les opérations lvconvert et pvmove. lvpoll n'initie pas de lui même ces opérations et ne doivent généralement être appelées directement.

OPTIONS

--polloperation {pvmove|convert|merge|merge_thin} Option obligatoire. pvmove réferre à une opération qui déplace des données. convert réferre à une augmentation qui augmente le nombre de copies redondantes des données maintenue par un mirroir. merge indique une opération de fusion qui n'implique pas de volumes thin. merge_thin indique une opération merge implique des snapshots thin.
--abort Annule un pvmove en progression
-A|--autobackup {y|n} Backup automatiquement les métadonnées après un changement
--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
--handlemissingpvs Utilisé quand l'opération doit gérer des PV manquant pour pouvoir continuer. Celà peut se produire quand lvconvert répare un mirroir avec un ou plusieurs périphériques en faute
-i|--interval Seconds Affiche la progression
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-t|--test Lance en mode test
-v|--verbose Mode verbeux

Exemples

Relance l'opération pvmove identifié par le volume logique vg00/pvmove0
lvm lvpoll --polloperation pvmove vg00/pvmove0
Annule la même opération
lvm lvpoll --polloperation pvmove --abort vg00/pvmove0
Trouver le nom du LV pvmove résultant d'un pvmove /dev/sda1
lvs -a -S move_pv=/dev/sda1
Relance la conversion mirroir de vg00/lvmirror
lvm lvpoll --polloperation convert vg00/lvmirror
Compléter la réparation du mirroir
lvm lvpoll --polloperation convert vg/damaged_mirror --handlemissingpvs
fusionner les snapshots:
lvm lvpoll --polloperation merge vg/snapshot_old
finir la fusion de snapshot thin
lvm lvpoll --polloperation merge_thin vg/thin_snapshot
^
23 mai 2016

htmlpdflatexmanmd




lvreduce

lvreduce

Réduire la taille d'un volume logique

   lvreduce permet de réduire la taille d'un volume logique. Il est nécessaire d'e s'assure que tout système de fichier dans le volume est redimensionner avant de lancer lvreduce pour que les extents qui sont enlevés ne soient pas utilisés.

   Réduire les volumes logique snapshot est supporté également. Mais pour changer le nombre de copies dans un volume logique en mirroir utiliser lvconvert. Les tailles seront arrondies si nécessaire, par exemple, la taille de volume doit être un nombre exacte d'extents et la taille d'un segment striped doit être un multiple du nombre de stripes.

OPTIONS

-A|--autobackup {y|n} [--commandprofile ProfileName
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-t|--test Lance en mode test
-v|--verbose Mode verbeux
-f|--force Force la réduction de la taille sans demander.
--noudevsync Désactive la synchronisation udev. Le processus n'attend pas de notification udev.
-l|--extents [-]LogicalExtentsNumber[%{VG|LV|FREE|ORIGIN} Réduit ou définis la taille du volume logique en unité d'extents logique. avec le signe '-' la valeur est soustraite de la taille actuelle et sans, la valeur est une taille absolue. Le nombre total d'extents physique libérés sera supérieur à cette valeur logique si, par exemple, le volume est mirroré. Le nombre peut également être exprimé en % total de l'espace dans le vg avec le suffixe %VG, relatif à la taille existante du volume logique avec le suffixe %LV, comme pourcentage de l'espace libre restant dans le VG avec les suffixe %FREE, ou (pour un snapshot) comme % de l'espace totale de l'origine avec le suffixe %ORIGIN. La valeur résultante pour la soustraction est arrondie à l'inférieur, pour la taille absolue la taille est arrondie au supérieur.
-L|--size [-]LogicalVolumeSize[bBsSkKmMgGtTpPeE] Réduit ou définis la taille lv en unité spécifiée. avec '-' la valeur est soustraite de la taille actuelle et sans, la valeur est absolue.
-n|--nofsck N'effectue pas de fsck avant de redimmensionner le système de fichier quand le système de fichier le nécessite.
-r|--resizefs Redimmensionne le système de fichier avec le Lv en utilisant fsadm.

Exemples

Réduire la taille du volume logique lvol1 dans le vg vg00 de 3 extents logiques
lvreduce -l -3 vg00/lvol1
^
23 mai 2016

htmlpdflatexmanmd




lvremove

lvremove

Supprimer un volume logique

   lvremove supprime un ou plusieurs volumes logiques. Les volumes logiques ne peuvent pas être désactivé ou supprimés s'ils sont ouverts (s'ils contiennent un système de fichier monté). Supprimer un volume logique origine supprime également tous les snapshots dépendants.

   Si le volume logique est clusterisé il doit être désactivé sur tous les nœuds dans le cluster avant qu'il puisse être supprimé. Un simple lvchange émis depuis un des nœuds peut le faire.

   Si les paramètres de configuration metadata/record lvs history est activé et le volume logique à supprimer forme une partie de l'historique d'au moins un volume logique qui est présent, alors une représentation simplifiée du volume logique sera retenu. Cela inclus le temps de suppression, la date de création, le nom, l'uuid, et le nom du volume group et permet de voir la chaîne des volumes snapshot thin même après que certains volumes logiques intermédiaire aient été supprimés. Les noms de tels volumes logique historique acquièrent un '-' comme préfixe (ex: '-lvol1') et ne peut pas être réactivé. Utiliser lvremove une seconde fois, avec les '-', pour le supprimer completement.

OPTIONS

-f, --force, -ff Supprimer les volumes logiques actifs sans confirmation. Pour traiter des pools endommagés, utiliser -ff
--nohistory Désactive l'enregistrement de l'historique des volumes logique qui sont supprimés.
--noudevsync Désactive la synchronisation udev. Le processus n'attend pas de notification udev.
-A|--autobackup {y|n} Backup automatiquement les métadonnées après un changement
--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-S|--select Selection Ne traite que les lignes qui matchent le critère donné
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-t|--test Lance en mode test
-v|--verbose Mode verbeux

Supprimer le volume logique actif lvol1 dans le vg vg00 sans demander de confirmation:
lvremove -f vg00/lvol1
Supprimer tous les volumes logique dans le volume group vg00:
lvremove vg00
^
23 mai 2016

htmlpdflatexmanmd




lvrename

lvrename

Renommer un volume logique

OPTIONS

-A|--autobackup {y|n} Backup automatiquement les métadonnées après un changement
--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-t|--test Lance en mode test
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-v|--verbose Mode verbeux
-f|--force Ne demande pas confirmation
--noudevsync Désactive la synchronisation udev. Le processus n'attend pas de notification udev.

Exemples

Renommer lvold dans le volume group vg02 en lvnew
lvrename /dev/vg02/lvold vg02/lvnew
Syntaxe alternative pour renommer ce volume logique
lvrename vg02 lvold lvnew
^
24 mai 2016

htmlpdflatexmanmd




lvresize

lvresize

Redimensionne un volume logique

OPTIONS

--alloc AllocationPolicy Sélectionne la stratégie d'allocation (anywhere|contiguous|cling|inherit|normal)
--noudevsync Désactive la synchronisation udev. Le processus n'attend pas de notification udev.
--commandprofile ProfileName Sélectionne le profile de configuration de commande
-i|--stripes Stripes Indique le nombre de stripes pour l'extension. Non applicable aux LV utilisant le format de métadonné originel.
-I|--stripesize StripeSize Donne le nombre de ko pour la granularité des stripes.
-l|--extents [+][-]LogicalExtentsNumber[%{VG|LV|PVS|FREE|ORIGIN} Étend ou définis la taille du volume logique en unités d'extensions logique. avec '+' la valeur est ajoutée à la taille actuelle, '-' la valeur est soustraite, et sans, la valeur est absolue. Le nombre total d'extents physiques alloués sera supérieur, par exemple, si le volume est mirroré. Ce nombre peut également être exprimé en % de l'espace total dans le VG avec %VG, relatif à la taille existante du LV avec %LV, de l'espace restant dans le PV avec %PVS, en pourcentage de l'espace total du volume logique d'origine avec %ORIGIN. La valeur résultante est arrondis au supérieur.
-L|--size [+][-]LogicalVolumeSize[bBsSkKmMgGtTpPeE] Étend ou définis la taille du volume logique en unité spécifiée. Avec un '+', la valeur est ajouté, '-' pour soustraire, sinon elle est prise comme valeur absolue.
--poolmetadatasize [+]MetadataVolumeSize[bBsSkKmMgG] Change ou définis la taille de métadonnées du pool thin. May: 16Gio
-f|--force Ne demande pas confirmation
-n|--nofsck N'effectue pas de fsck avant d'étendre le système de fichier qu'en c'est nécessaire.
-r|--resizefs Redimensionne le système de fichier en même temps que le volume logique en utilisant fsadm

Exemples

Étendre un volume logique vg1/lv1 de 16Mo en utilisant les extents physiques /dev/sda:0-1 et /dev/sdb:0-1 pour l'allocation des extents:
lvresize -L+16M vg1/lv1 /dev/sda:0-1 /dev/sdb:0-1
^
24 mai 2016

htmlpdflatexmanmd




lvs

lvs

Affiche des informations sur les volumes logiques

OPTIONS

--all Inclus des informations sur les volumes logiques internes
--aligned Utiliser avec --separator pour aligner les colonnes de sortie
--binary Utilise le valeurs binaire 0 ou 1 au lieu des valeurs litérale pour les colonnes qui ont exactement 2 valeurs valides
--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
--ignorelockingfailure Permet de traiter des opérations de métadonnées lecture-seule même si le module de lock échoue. Utile dans un script init si le répertoire de lock est monté en lecture seul
--ignoreskippedcluster Permet de quitter avec un status non-zero si la commande est lancé sans lockup clusterisé et que certains vg clusterisés doivent être ignorés
--nameprefixes Ajoute un préfixe LVM2_ plus le nom du champ dans la sortie. Utile avec --neheadings pour produire une liste de paires champ=valeur qui peuvent être utilisées en variable d'environnement.
--noheadings Supprime les lignes d'en-tête
--nosuffix Supprime le suffixe pour les tailles. Utiliser avec --units si besoin
-o|--options [+|-|#]Field[,Field...] Liste de colonnes à afficher (-) ou enlever (-). '#' compacte les colonnes données. lv_all sélectionne toutes les colonnes de volume logiques, et lvseg_all sélectionne toutes les colonnes de segment de volume logique.
-O|--sort [+|-]Key1[,[+|-]Key2...] Liste de colonnes pour l'ordre de trie.
-P|--partial Fait de son mieux pour fournir un accès aux volumes group qui sont seulement disponible partiellement
--rows Affiche les colonnes brutes
--segments Produit une ligne de sortie pour chaque allocation contigue d'espace dans chaque volume physique
-S|--select Selection Affiche seulement les lignes qui matchent le critère donné
--separator Separator Chaîne à utiliser pour séparer chaque colonne
--unbuffered Produit une sortie immédiatement sant trier ou aligner les colonnes
--units hHbBsSkKmMgGtTpPeE Toutes les tailles affichée sont exprimé avec l'unité spécifiée.
--unquoted avec --nameprefixes, affiche les valeurs sans guillemets
-v|--verbose Mode verbeux
-H, --history Inclus l'historique des volumes logique dans la sortie
^
23 mai 2016

htmlpdflatexmanmd




lvscan

lvscan

Scan tous les disques à la recherche de volumes logiques

   lvscan scanne tous les volumes group ou tous les périphériques blocks supportés dans le système à la recherche des volumes logiques. La sortie consiste d'une ligne pour chaque volume logique indiquant s'il est actif, un origine ou un snapshot, la taille et sa stratégie d'allocation. Utiliser lvs ou lvdisplay pour obtenir des informations plus compréhensibles.

OPTIONS

--all Inclus des informations sur les volumes logiques interne tel que les mirroirs.
--cache LogicalVolume Uniquement si lvmetad est utilisé. Émet un rescan des labels physiques et des zones de métadonnées de tous les PV que le volume logique utilise. Peut être utilisé quand un volume logique RAID devient dégradé, pour mettre à jours les informations sur les volumes physique indisponible. Seulement nécessaire si le volumen logique n'est pas monitoré par dmeventd
--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
--ignorelockingfailure Permet de traiter des opérations de métadonnées lecture-seule même si le module de lock échoue. Utile dans un script init si le répertoire de lock est monté en lecture seul
-P|--partial Fait de son mieux pour fournir un accès aux volumes group qui sont seulement disponible partiellement
-v|--verbose Mode verbeux
^
23 mai 2016

htmlpdflatexmanmd




pvchange

pvchange

Change les attributs d'un volume physique

OPTIONS

--addtag Tag Ajoute le tag spécifié. Peut être spécifié plusieurs fois
-A|--autobackup {y|n} Backup automatiquement les métadonnées après un changement
--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-f|--force Ne demande pas confirmation
--deltag Tag Supprime le tag spécifié
--metadataignore {y|n} Ignore ou on les zones de métadonnées dans ce volume physique. Si ces zones sont ignorées, LVM ne stocke pas de métadonnées dans ces zones dans ces volumes physiques
-S|--select Selection Affiche seulement les lignes qui matchent le critère donné
-t|--test Lance en mode test
-v|--verbose Mode verbeux
-a|--all Si le chemin du PV n'est pas spécifié sur la ligne de commande, tous les volumes physiques sont recherchés
-x|--allocatable {y|n} Active/désactive l'allocation d'extents physique dans ce volume physique
-u|--uuid Génère un nouvel UUID aléatoire pour les volumes physiques spécifiés

Exemples

Désactiver l'allocaction d'extents physiques:
pvchange -x n /dev/sdk1
^
23 mai 2016

htmlpdflatexmanmd




pvck

pvck

Vérifier les métadonnées des volumes physiques

OPTIONS

--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-v|--verbose Mode verbeux
--labelsector sector Par défaut, 4 secteurs du volume physique sont scannés pour un label LVM, en commençant au secteur 0. Ce paramètre permet de spécifier un secteur différent de départ. par exemple supposons une table de partition corrompue ou perdu dans /dev/sda, mais vous suspectez qu'il y avait une partition LVM à 100MiB. Cette zone du disque peut être scannée en utilisant la valeur 204800 (100*1024*1024/512)
^
06 juin 2016

htmlpdflatexmanmd




pvcreate

pvcreate

initialiser un disque ou une partition pour LVM

   Initialise le périphériques pour l'utiliser avec LVM. Chaque volume physique peut être un disque, une partition, un fichier loopback ou un périphérique méta. Pour les partitions DOS, l'id de partition devrait être 0x8e. Pour une partition GPT, l'id est E6D6D379-F507-44C2-A23C-238F2A3DF928. Pour les disques entiers, la table de partition doit être effacée.

OPTIONS

--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-t|--test Lance en mode test
-v|--verbose Mode verbeux
-f[f]|--force [--force Force la création sans confirmation
-y|--yes Répond yes à toutes les questions
--labelsector Par défaut le PV est labelisé avec un identifiant LVM dans son second secteur. Cette option permet d'utiliser un secteur différent au défaut du disque (entre 0 et 3).
--bootloaderareasize size Créé une zone bootloader séparé de taille spécifiée à côté des données dans laquelle lvm n'alloue pas d'extents. Le début de cette zone est toujours alignée. Pour voir cette zone, utiliser pvs -o +pv_ba_start,pv_ba_size
-M|--metadatatype type Spécifie quel type de métadonnée à utiliser
--[pv]metadatacopies NumberOfCopies Nombre de zones de métadonées à définir dans chaque PV (0, 1 ou 2). à 2, 2 copies des métadonnées du VG sont maintenus dans le PV, une avant, et une à la fin.
--metadatasize size Quantité d'espace approximative à définir pour chaque zone de métadonnées. La taille peut être arrondie.
--metadataignore {y|n} Ignore ou non les zones de métadonnées dans ce volume physique. Si ces zones sont ignorées, LVM ne stocke pas de métadonnées dans ces zones dans ces volumes physiques
--dataalignment alignment Aligne le début des données à un multiple de ce nombre. Ensuite, en créant un VG, physicalExtentSize devrait être spécifié de manière approprié.
--dataalignmentoffset alignment_offset Décale le début de la zone des données
--restorefile file avec --uuid, extrait l'emplacement et la taile des données dans le PV depuis le fichier (produit par vgcfgbackup) et s'assure que les métadonnées que le programme produit est consistant.
--norestorefile Avec --uuid, permet de spécifier un uuid sans fournir un backup des métadonnées
--setphysicalvolumesize size Remplace la taille automatiquement détectée du PV.
-u|--uuid uuid Définis l'uuid pour le périphériques
-Z|--zero {y|n} Spécifie si les 4 premiers secteurs (2048octets) du périphériques devraient être effacés.

Exemples

Initialise la partition 4 sur un disque SCSI et le 5ème disque SCSI:
pvcreate /dev/sdc4 /dev/sde
Si le 2ème disque est un disques avec des secteurs de 4Kio qui compensent pour le partitionnement windows (le secteur 7 est le block logique le plus bas alligné, les serveurs 4Kio commencent à LBA -1, et en consequence le serveur 63 est aligné sur les limites 4Kio), le définir manuellement:
pvcreate --dataalignmentoffset 7s /dev/sdb
^
24 mai 2016

htmlpdflatexmanmd




pvdisplay

pvdisplay

Affiche les attributs d'un volume physique

   pvdisplay permet de voir les attributs d'un ou plusieurs volumes physiques comme la taille, taille d'extents physique, espace utilisé pour les métadonnées, etc.

OPTIONS

-c|--colon Génère une sortie séparée par des ',' pour simplifier le traitement pas des scripts. pvs a un meilleur contrôle sur la sortie.
-C|--columns Affiche la sortie en colonnes, l'équivalent de pvs.
--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
--ignorelockingfailure Permet de traiter des opérations de métadonnées lecture-seule même si le module de lock échoue. Utile dans un script init si le répertoire de lock est monté en lecture seul
--ignoreskippedcluster Permet de quitter avec un status non-zero si la commande est lancé sans lockup clusterisé et que certains vg clusterisés doivent être ignorés
--maps Affiche le mapping des extents physiques aux volumes logiques et extents logiques.
--nosuffix Supprime le suffixe pour les tailles. Utiliser avec --units si besoin
-s|--short Affiche seulement la taille des volumes physique donné
-S|--select Selection Affiche seulement les lignes qui matchent le critère donné
--units hHbBsSkKmMgGtTpPeE Toutes les tailles affichée sont exprimé avec l'unité spécifiée.
-v[v]|--verbose Mode verbeux
--aligned Utiliser avec --separator pour aligner les colonnes de sortie
--binary Utilise le valeurs binaire 0 ou 1 au lieu des valeurs litérale pour les colonnes qui ont exactement 2 valeurs valides
-a|--all Inclus des informations sur les périphériques qui n'ont pas été initialisé avec pvcreate
--noheadings Supprime les lignes d'en-tête
-o|--options [+|-|#]Field[,Field...] Liste de colonnes à afficher (-) ou enlever (-). '#' compacte les colonnes donnéespv_all sélection toutes les colonnes de volume physique, et pvseg_all sélectionne toutes les colonnes de segment de volume physique.
-O|--sort [+|-]Key1[,[+|-]Key2...] Liste de colonnes pour l'ordre de trie.
--separator Separator Chaîne à utiliser pour séparer chaque colonne
--unbuffered Produit une sortie immédiatement sant trier ou aligner les colonnes
^
25 mai 2016

htmlpdflatexmanmd




pvmove

pvmove

Déplacer des extents physiques

   pvmove permet de déplacer des extents physiques alloués dans un PV vers un ou plusieurs auters VG. On peut optionnellement spécifier un volume logique auquel cas seul les extents utilisés par ce LV seront déplacés. Si aucun PV de destination n'est spécifié, les règles d'allocation normales pour le volume group sont utilisés.

   pvmove fonctionne comme suit:

1. Un volume logique temporaire pvmove est créé pour stocké les détails de tous les mouvements de données requis.
2. Tout volume logique dans le volume group est recherché pour les données contigues qui doivent bouger en accord avec les arguments de la ligne de commande. Pour chaque portion de données trouvé, un nouveau segment est ajouté à la fin du LV pvmove. Ce segment prend la forme d'un mirroir temporaire pour copier la donnée depuis l'emplacement original vers le nouvel emplacement. Le LV d'origine est mis à jours pour utiliser le nouveau segment temporaire dans le LV pvmove au lieu d'accéder à la données directement.
3. Les métadonnées du volume group sont mis à jours sur disque
4. Le premier segment du volume logique pvmove est activé et démarré pour mirrorer la première partie des données. Seulement un segment est mirroré à la fois.
5. Un service vérifie la progression. Quand il détecte que le premier mirroir temporaire est in-sync, il casse ce mirroir pour que seul le nouvel emplacement soit utilisé et écrit un checkpoint dans les métadonnées du volume group sur disque. Puis il active le mirroir pour le segment suivant
6. Quand il n'y a plus de segment à mirrorer, le volume logique temporaire est supprimé et les métaddonées du volume group est mis à jours pour que les volumes logique reflètent les nouveaux emplacement.

   Si l'option --atomic est utilisé, une approche légèrement différente est utilisée pour le déplacement. Un volume pvmove temporaire est également créé pour stocker les détails de tous les données en mouvement. Ce LV temporaire contient tous les segments de divers LV qui doivent être déplacés. Cependant cette fois, un volume logique identique est alloué qui contient le même nombre de segments et un mirroire est créé pour copier le contenu du premier LV temporaire vers le second. Quand une copie complète est accomplie, les volume logiques temporaire sont supprimés, laissant derrière les segments sur le volume physique de destinatio. Si une annulation est émis durant le déplacement, tous les volumes logique à déplacer resteront dans le volume physique source.

OPTIONS

--abort Annule tous les déplacement en cours. Si --atomic, tous les volumes logique restent dans le PV source.
--alloc AllocationPolicy Sélectionne la stratégie d'allocation (anywhere|contiguous|cling|inherit|normal)
--atomic Rend l'opération atomique. Cela s'assure que tous les volumes logiques affectés sont déplacés dans la destination ensemble.
-b|--background Lance le service en tâche de fond
--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-i|--interval Seconds interval d'affichage de la progression
--noudevsync Désactive la synchronisation udev. Le processus n'attend pas de notification udev.
-v|--verbose Mode verbeux
-n|--name Déplace seulement les extents appartenant au volume logique spécifié

Exemples

Déplacer tous les extents physique utilisés par un LV dans /dev/sdb1 vers des extents physique ailleurs dans le volume group:
pvmove /dev/sdb1
Additionnellement, un périphérique de destination peut être spécifié:
pvmove /dev/sdb1 /dev/sdc1
Effectuer l'action seulement sur les extents appartiennent à un volume logique lvol1:
pvmove -n lvol1 /dev/sdb1 /dev/sdc1
Au lieu de déplacer le contenu de tous le périphérique, il est possible de spécifier une plage d'extents physiques, par exemple 1000 à 1999:
pvmove /dev/sdb1:1000-1999
ou
pvmove /dev/sdb1:1000-1999 /dev/sdc1:0-999
Si la source et la destination sont sur le même disque, la stratégie d'alloctation anywhere peut être nécessaire:
pvmove --alloc anywhere /dev/sdb1:1000-1999 /dev/sdb1:0-999
La partie d'un volume logique spécifique présent dans une plage d'extents physique peut également être déplacé:
pvmove -n lvol1 /dev/sdb1:1000-1999 /dev/sdc1
^
23 mai 2016

htmlpdflatexmanmd




pvremove

pvremove

Supprimer un volume physique

   pvremove supprime la table dans un périphérique pour que LVM ne le reconnaisse plus comme volume physique.

OPTIONS

-ff, --force --force Force la suppression d'un volume physique appartenant à un volume group existant. Normalement, vgreduce devrait être utilisé au lieu de cette commande. Il n'est pas possible de supprimer un volume physique utilisé par un volume logique actif
-y, --yes Répond oui à toutes les questions
--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-t|--test Lance en mode test
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-v|--verbose Mode verbeux
^
23 mai 2016

htmlpdflatexmanmd




pvresize

pvresize

Redimensionne un disque ou une partition utilisé par LVM2

   pvresize redimensionne le volume physique qui peut déjà être dans un volume group et avoir des volumes logiques actifs.

OPTIONS

--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-t|--test Lance en mode test
-v|--verbose Mode verbeux
--setphysicalvolumesize size Remplace la taille automatiquement détectée du PV

Exemples

Étend le PV sur /dev/sda1 après avoir agrandi la partition avec fdisk:
pvresize /dev/sda1
Réduit le PV sur /dev/sda1 avant de réduire la partition avec fdisk:
pvresize --setphysicalvolumesize 40G /dev/sda1

Restrictions

   pvresize refuse de réduire le volume physique s'il a alloué des extents après l'endroit ou la nouvelle fin devrait être. Dans le future, il devrait les relocaliser ailleurs dans le volume group s'il y a suffisamment d'espace libre, comme le fait pvmove. pvresize ne fonctionne pas correctement dans les volumes LVM1.
^
24 mai 2016

htmlpdflatexmanmd




pvs

pvs

Affiche des informations sur les volumes physiques

OPTIONS

--all Inclus des informations sur les périphériques qui n'ont pas été initialisé avec pvcreate
--aligned Utiliser avec --separator pour aligner les colonnes de sortie
--binary Utilise les valeurs binaire 0 ou 1 au lieu des valeurs littérales pour les colonnes qui ont exactement 2 valeurs valides
--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
--ignorelockingfailure Permet de traiter des opérations de métadonnées lecture-seule même si le module de lock échoue. Utile dans un script init si le répertoire de lock est monté en lecture seul
--ignoreskippedcluster Permet de quitter avec un status non-zero si la commande est lancé sans lockup clusterisé et que certains vg clusterisés doivent être ignorés
--nameprefixes Ajoute un préfixe LVM2_ plus le nom du champ dans la sortie. Utile avec --neheadings pour produire une liste de paires champ=valeur qui peuvent être utilisées en variable d'environnement.
--noheadings Supprime les lignes d'en-tête
--nosuffix Supprime le suffixe pour les tailles. Utiliser avec --units si besoin
-o|--options [+|-|#]Field[,Field...] Liste de colonnes à afficher (-) ou enlever (-). '#' compacte les colonnes données. pv_all sélectionne toutes les colonnes de volume physique, et pvseg_all sélectionne toutes les colonnes de segment de volume physique.
-O|--sort [+|-]Key1[,[+|-]Key2...] Liste de colonnes pour l'ordre de trie.
-P|--partial Fait de son mieux pour fournir un accès aux volumes group qui sont seulement disponible partiellement
--rows Affiche les colonnes brutes
--segments Produit une ligne de sortie pour chaque allocation contigue d'espace dans chaque volume physique
-S|--select Selection Affiche seulement les lignes qui matchent le critère donné
--separator Separator Chaîne à utiliser pour séparer chaque colonne
--unbuffered Produit une sortie immédiatement sant trier ou aligner les colonnes
--units hHbBsSkKmMgGtTpPeE Toutes les tailles affichée sont exprimé avec l'unité spécifiée.
--unquoted avec --nameprefixes, affiche les valeurs sans guillemets
-v|--verbose Mode verbeux
^
25 mai 2016

htmlpdflatexmanmd




pvscan

pvscan

Scanne tous les disques à la recherche des volumes physiques

   pvscan opère différemment quand il est utilisé avec lvmetad

   Scanner des disques est nécessaire pour lire les métadonnées LVM et identifier les PV. Une fois lu, lvmetad met en cache ces métadonnées pour que les commandes lvm puis les lire sans scanner les disques à nouveau.

   Quand lvmetad est utilisé, les nouveaux disques doivent être scannés avec vpscan --cache.

Notes

- En donnant des périphériques en argument, pvscan --cache ne scanne que ceux spécifiés
- Les règle udev LVM et services systemd sont utilisés pour initier le scan automatique
- l'option devices/global_filter de lvm.conf permet de filtrer les disques à scanner.
- Si lvmedat est démarré ou redémarré, tous les périphériques doivent être rescannés
- lvmetad ignore les anciens formats de métadonnées
- Pour notifier lvmetad sur un périphérique qui n'est plus présent, les numéros mineur et majeur doivent être donnés

Activation automatique

   Quand les services système détectent un nouveau périphérique LVM, la première étape est de scanner automatiquement et de mettre en cache les métadonnée du périphérique, avec pvscan --cache. La seconde étape est d'activer automatiquement les LV qui sont présent dans le nouveau périphérique. Cette auto-activation est faite par la même commande pvscan --cache quand l'option -a|--activate ay est inclus.

auto-activation des VG ou LV peut être activé/désactivé en utilisant:
lvm.conf activation/auto_activation_volume_list

   Quand ce paramètre est non-définis, tous les LV sont auto-activés.

   Quand un VG ou un LV n'est pas auto-activé, l'activation traditionnelle en utilisant vgchange ou lvchange -a|--activate est nécessaire.

Notes

- l'auto-activation de pvscan peut être faite seulement en combinaison avec --cache
- L'auto-activation est désignée par un argument "a" dans "-a|--activate ay". Cela signifie de distinguer les commandes générées par le système des commandes utilisateur, bien qu'elle peut être utilisée dans une commande d'activation. Quand utilisé, l'auto-activation volume_list est appliqué.
- L'auto-activation n'est pas encore supporté pour les LV qui font partie de volumes groupe partiel ou clusterisé.

OPTIONS

--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-v|--verbose Mode verbeux
--ignorelockingfailure Permet de traiter des opérations de métadonnées lecture-seule même si le module de lock échoue. Utile dans un script init si le répertoire de lock est monté en lecture seul
-e|--exported Affiche seulement les volumes physique appartenant à un volume group exporté
-n|--novolumegroup Affiche seulement les volumes physiques n'appatenant pas à un volume group
-s|--short Format court
-u|--uuid Affiche les UUID en plus des noms de périphérique
-a|--activate ay Active automatiquement les volumes logiques
-b|--background Lance en tâche de fond
--cache --major major --minor minor Scanne un ou plusieurs périphériques et envoie les métadonnées à lvmetad
^
25 avril 2017

htmlpdflatexmanmd




thin_check

thin_check

Valide les métadonnées de provisionnement léger dans un périphérique ou fichier

   thin_check vérifie les métadonnées de provisionning créé par DM dans un périphérique ou un fichier

OPTIONS

-q, --quiet mode silencieux
--clear-needs-check-flag efface le flage needs_check-flag au cas où la vérification a réussie.
--super-block-only Ne vérifie que la présence du superbloc
--skip-mappings ne vérifie pas le mappage de block qui constitue la majeur partie des métadonnées
--ignore-non-fatal-errors Ignore certaines erreurs non-fatales
^
25 avril 2017

htmlpdflatexmanmd




thin_dump

thin_dump

dump les métadonnées de provisionnement léger sur stdout

   thin_dump dump les métadonnées de provisionnement légier créé par la cible de provisionnement léger device-mapper sur stdout pour l'analyse ou post-traitement au format XML ou human-readable. Cet outil ne peut pas être lancé sur des métadonnées live sauf si --metadata-snap est utilisé.

OPTIONS

-f, --format {xml|human-readable} Format de sortie
-r, --repair Répare les métadonnée durant le dump
-m, --matadata-snap [block#] dump le snapshot de métadonnées.
^
25 avril 2017

htmlpdflatexmanmd




thin_metadata_size

thin_metadata_size

calculateur de taille de périphérique de métadonnées de provisionnement léger

   thin_metadata_size calcule la taille des métadonnées de provisionnement léger basé sur la taille de block des périphériques de provisionnement léger. La taille du pool et le nombre maximum de tous les périphériques provisionnés et snapshots. Parce que les pools de provisionnement léger maintiennent une grande variété de variables, cet outil est nécessaire pour fournir une taille initiale par défaut.

OPTIONS

-b, --block-size BLOCKSIZE[bskKmMgGtTpPeEzZyY] Taille de block des périphériques.
-s, --pool-size POOLSIZE[bskKmMgGtTpPeEzZyY] Taille du pool
-m, --max-thins #[bskKmMgGtTpPeEzZyY] Somme maximum de tous les périphériques et snapshots
-u, --unit {bskKmMgGtTpPeEzZyY} Unité à afficher pour la sortie
-n, --numeric-only [short|long] Limite la sortie à la taille avec optionnellement l'unité

Exemples

Calculer la taille pour une taille de block de 64Kio, une taille de pool de 1Tio et un nombre max de périphériques et snapshots de 1000:
thin_metadata_size -b64k -s1t -m1000
avec les options longues pour une taille de block de 1Gio, taille de pool de 1Po et un nombre max de périphériques et snapshots de 1 million:
thin_metadata_size --block-size=1g --pool-size=1P --max-thins=1M --unit=G --numeric-only
Idem avec les unités complètes
thin_metadata_size --block-size=1gibi --pool-size=1petabytes --max-thins=1mega --unit=G --numeric-only=short
avec une chaîne spécifiant l'unité
thin_metadata_size --block-size=1gibi --pool-size=1petabytes --max-thins=1mega --unit=G -nlong
^
25 avril 2017

htmlpdflatexmanmd




thin_repair

thin_repair

Répare les métadonnées de provisionnement léger

   thin_repair lit les métadonnées de provisionnement léger, les répares et les écrit dans un autre périphérique ou fichier. Cet outil ne peut être lancé sur des metadonnées live

OPTIONS

-i, --input {device|file} Fichier ou périphérique d'entrée
-o, --output {device|file} fichier ou périphérique de sortie. Si un fichier est utilisé, il doit être préalloué et suffisamment grand pour maintenir les métadonnées

Exemples

Lit les métadonnées dans le fichier metadata, le répare et l'écrit dans /dev/vg/metadata:
thin_repair -i metadata -o /dev/vg/metadata
^
25 avril 2017

htmlpdflatexmanmd




thin_restore

thin_restore

Restore les métadonnées de provisionnement léger d'un fichier vers un périphérique ou fichier

   thin_restore restaure les métadonnées de provisionnement léger créés par la cile DM dumpée au format XML, peut optionnellement être pré-traité avant de le restaurer.

OPTIONS

-q, --quiet mode silencieux
-i, --input {device|file} Fichier ou périphérique d'entrée
-o, --output {device|file} fichier ou périphérique de sortie. Si un fichier est utilisé, il doit être préalloué et suffisamment grand pour maintenir les métadonnées
^
25 avril 2017

htmlpdflatexmanmd




thin_rmap

thin_rmap

Affiche un map inversé d'une région de provisionnement léger de blocks depuis le périphérique de métadonnées

OPTIONS

--region ‹block range› Affiche la map inversée

Exemples

Affiche la map inversé pour les blocks de pool 5..45 (==5..44 inclusif)
thin_rmap --region 5..45 /dev/pool-metadata
^
23 mai 2016

htmlpdflatexmanmd




vgcfgbackup

vgcfgbackup

Sauvegarde l'aire descripteur du volume group

   Permet de backuper les métadonnées des volumes group. Sans nom de volume group, tous sont sauvegardés. Dans une installation par défaut, chaque volume group et sauvegardé dans un fichier séparé portant le nom du volume group dans /etc/lvm/backup.

OPTIONS

-f, --file spécifie un fichier alternatif pour le backup. Sans nom de vg spécifié, %s est remplacé par le nom du VG.
--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
--ignorelockingfailure Permet de traiter des opérations de métadonnées lecture-seule tel que lvchange -ay et vgchange -ay même si le module de lock échoue. Utile dans un script init si le répertoire de lock est monté en lecture seul
-P|--partial Fait de son mieux pour fournir un accès aux volumes group qui sont seulement disponible partiellement
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-v|--verbose Mode verbeux
^
23 mai 2016

htmlpdflatexmanmd




vgcfgrestore

vgcfgrestore

Restaure l'aire de descripteur de volume group

   vgcfgrestore permet de restaurer les métadonnées du volumes group depuis un fichier de sauvegarde produit par vgcfgbackup. Si aucun backup n'est spécifié, le plus récent est utilisé. Utiliser --list pour lister les sauvegardes disponible et les fichiers archives

OPTIONS

-l, --list Liste les fichiers de sauvegarde et archive pertinent pour le VG spécifié.
-f, --file filename Nom d'un fichier de sauvegarde, généralement créé avec vgcfgbackup.
--force Nécessaire pour restaurer les métadonnées avec les volumes thin. note: de nombreux changements ne peut pas être inversé dans les métadonnées thin, on peut perdre des données si la restoration ne matche par les métadonnées du pool thin précisemment.
--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-M|--metadatatype 1|2 Spécifie quel type de métadonnée utiliser
-t|--test Lance en mode test
-v|--verbose Mode verbeux

Remplacer des volumes physiques

   vgdisplay --partial --verbose affiche les UUID et tailles de tout PV qui ne sont plus présents. Si un PV dans le VG est perdu et que l'on souhaite substituer un autre de même taille, utiliser vpcreate --restorefile filename --uuid uuid pour l'initialiser avec le même UUID que le PV manquant. Puis utiliser vgcfgrestore --file filename pour restaurer les métadonnées du VG.
^
08 juin 2016

htmlpdflatexmanmd




vgchange

vgchange

Changer les attributs d'un volume group

OPTIONS

--addtag Tag Ajoute le tag spécifié. Peut être spécifié plusieurs fois
--alloc AllocationPolicy Sélectionne la stratégie d'allocation (anywhere|contiguous|cling|inherit|normal)
-A|--autobackup {y|n} Backup automatiquement les métadonnées après un changement
-a|--activate [a|e|s|l] {y|n} Contrôle la disponibilité des volumes logiques dans le volume groupe. Si l'autoactivation est utilisée (-aay), chaque volume logique est activé seulement s'il match un élément dans le jeu activation/auto_activation_volume dans lvm.conf. L'activation d'un volume logique créé un lien /dev/VolumeGroupName/LogicalVolumeName pointant vers le nœud. Ce lien est supprimé à la désactivation. Dans un VG clusterisé, clvmd est utilisé pour l'activation, -aey active le LV en mode exclusive, permettant à un seul nœud d'activer le LV. -asy active le LV en mode partagé. -ay, active le LV en mode partagé si le type de LV permet l'accès concurrent, sinon en mode exclusif. Avec -an, clvmd tente de désactiver le LV sur tous les nœuds. -aly active le LV seulement sur le nœud local.
--activationmode {complete|degraded|partial} Le mode d'activation détermine si les volumes logiques sont autorisés à être activés quand il y a des volumes physiques manquant. complete est le plus restrictif. degraded autorise les LV RAID même si des PV sont manquant (mirror n'est pas considéré comme LV raid). partial permet d'activer tout LV même si des portions sont manquants
-K|--ignoreactivationskip Ignore le flag skip des LV durant l'activation.
--monitor {y|n} Démarre/arrête la supervision d'un volume logique mirroré ou snapshot avec dmeventd, si installé. Si un périphérique utilisé par un mirroir supervisé reporte une erreur d'E/S, l'erreur est gérée en accord avec mirror_image_fault_policy et mirror_log_fault_policy dans lvm.conf
--poll {y|n} Sans le polling de transformation en tâche de fond d'un volume logique le processus ne se complète jamais. S'il y a un pvmove ou lvconvert incomplet, utiliser --poll y pour relancer le processus.
-c|--clustered {y|n} Si le lock clustered est activé, indique si ce VG est partagé avec d'autres nœuds dans le cluster ou s'il contient seulement des disques locaux non visible aux autres nœuds.
-u|--uuid Génère un nouvel UUID aléatoire pour les volumes groups spécifiés
--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
--deltag Tag Supprime le tag spécifié
--detachprofile Détache tous les profiles de configuration de métadonnées attachés aux VG donnés.
--ignorelockingfailure Permet de traiter des opérations de métadonnées lecture-seule même si le module de lock échoue. Utile dans un script init si le répertoire de lock est monté en lecture seul.
--ignoremonitoring Ne tente pas d'interragir avec dmeventd sauf si --monitor est spécifié.
--ignoreskippedcluster Permet de quitter avec un status non-zero si la commande est lancé sans lockup clusterisé et que certains vg clusterisés doivent être ignorés.
--sysinit Indique que vgchange est invoqué à l'initialisation du système, avant que les systèmes de fichier soient accessibles. Est équivalent à --ignorelockingfailure --ignoremonitoring --poll n et définir la variable d'environnement LVM_SUPPRESS_LOCKING_FAILURE_MESSAGES.
--noudevsync Désactive la synchronisation udev. Le processus n'attend pas de notification udev.
--lock-start Démarrare le lockspace du VG partagé dans lvmlockd. les locks lvmlockd deviennent disponibles pour le VG, permettant à LVM d'utiliser le vg.
--lock-stop Stop le lockspare du VG partagé dans lvmlockd.
--lock-type LockType Change le type de lock VG
-l|--logicalvolume MaxLogicalVolumes Change le nombre maximum de LV d'un VG inactif
-p|--maxphysicalvolumes MaxPhysicalVolumes Change le nombre maximum de volumes physiques qui peuvent appartenir à ce VG. Pour les VG avec un format de métadonnées lvm1, la limite est 255. Au format lvm2, 0 supprime cette restriction.
--metadataprofile ProfileName Sélectionne le profile de configuration des métadonnées à utiliser
--[vg]metadatacopies NumberOfCopies|unmanaged|all Définis le nombre de copies de métadonnées dans le volume group. à une valeur autre que 0, lvm gère automatiquement le flag 'metadataignore' dans les volumes physique pour obtenir le nombre de copies des métadonnées. 'unmanaged', lvm ne gère pas automatiquement le flag. 'all', lvm efface tous les flags dans toutes les zones de métadonnées dans le vg, puis passe en unmanaged.
-P|--partial Définis, les outils fond de leur mieux pour fournir un accès aux volumes group qui sont seulement disponible partiellement. Quand un partie d'un volume logique est manquant, /dev/ioerror est substitué, et dmsetup peut être utilisé pour retourner les erreurs I/O.
-s|--physicalextentsize PhysicalExtentSize[bBsSkKmMgGtTpPeE] Change la taille d'extent physique dans les volumes physiques de ce VG. Avant d'augmenter la taille d'extent, utiliser lvresize, pvresize et/ou pvmove.
-S|--select Selection Critère de sélection
--systemid SystemID Change le system_id du VG.
--refresh Si un volume logique dans le volume group est actif, recharge ses métadonnées. Ce n'est pas nécessaire dans une opération normale, mais est utile si quelque-chose ne va pas ou en faisant un cluster manuellement.
-t|--test Lance en mode test
-v|--verbose Mode verbeux
-x|--resizeable {y|n} Active/désactive l'extension/réduction de ce volume group avec/par les volumes physique

Exemples

Active tous les VG connus dans le système
vgchange -a y
Change le nombre maximum de volumes logique du VG inactif vg00 à 128
vgchange -l 128 /dev/vg00
^
23 mai 2016

htmlpdflatexmanmd




vgck

vgck

Vérifie les métadonnées de volume group

   vgck vérifie les métadonnées LVM pour chaque VG.

OPTIONS

--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-v|--verbose Mode verbeux
^
23 mai 2016

htmlpdflatexmanmd




vgconvert

vgconvert

Convertisseur de format des métadonnées

OPTIONS

--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-t|--test Lance en mode test
-v|--verbose Mode verbeux
--labelsector Par défaut, 4 secteurs du volume physique sont scannés pour un label LVM, en commençant au secteur 0. Ce paramètre permet de spécifier un secteur différent de départ
--bootloaderareasize size Créé une zone bootloader séparée à la taille spécifiée à côté de la zone de données
-M|--metadatatype type Spécifie quel type de métadonnée à utiliser
--pvmetadatacopies NumberOfCopies Nombre de zones de métadonnées à définir dans chaque PV (0,1 ou 2)
--metadatasize size Quantité d'espace approximative à définir pour chaque zone de métadonnées. La taille peut être arrondie.

Exemples

Convertis le volume group vg1 du format LVM1 vers LVM2:
vgconvert -M2 vg1

Récupération

   Utiliser pvscan pour voir quels PV ont perdu leur métadonnées. Lancer pvcreate avec --uuid et --restorefile dans chaque PV pour le reformater, en utilisant le fichier archive que vgconvert a créé au début de la procédure. Finalement, lancer vgcfgrestore avec ce fichier archive pour restaurer les métadonnées d'origine.
^
08 juin 2016

htmlpdflatexmanmd




vgcreate

vgcreate

Créer un volume group

OPTIONS

--addtag Tag Ajoute le tag spécifié. Peut être spécifié plusieurs fois
--alloc AllocationPolicy Sélectionne la stratégie d'allocation (anywhere|contiguous|cling|inherit|normal)
-A|--autobackup {y|n} Backup automatiquement les métadonnées après un changement
-c|--clustered {y|n} Si le locking est activé, est à yes par défaut, indiquant que ce volume group est partagé avec d'autres nœuds dans le cluster.
--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-l|--maxlogicalvolumes MaxLogicalVolumes Définis le nombre maximum de LV du VG
-M|--metadatatype type Spécifie quel type de métadonnée utiliser
--metadataprofile ProfileName Sélectionne le profile de configuration des métadonnées à utiliser
-p|--maxphysicalvolumes MaxPhysicalVolumes Définis le nombre maximum de volumes physiques qui peuvent appartenir à ce VG. Pour les VG avec un format de métadonnées lvm1, la limite est 255. Au format lvm2, 0 supprime cette restriction.
--[vg]metadatacopies NumberOfCopies|unmanaged|all Définis le nombre de copies de métadonnées dans le volume group. à une valeur autre que 0, lvm gère automatiquement le flag 'metadataignore' dans les volumes physique pour obtenir le nombre de copies des métadonnées. 'unmanaged', lvm ne gère pas automatiquement le flag. 'all', lvm efface tous les flags dans toutes les zones de métadonnées dans le vg, puis passe en unmanaged.
-s|--physicalextentsize PhysicalExtentSize[bBsSkKmMgGtTpPeE] Définis la taille d'extent physique dans les volumes physiques de ce VG
--shared Créé un VG partagé en utilisant lvmlockd
--systemid SystemID Définis le system_id du VG.
-t|--test Lance en mode test
-v|--verbose Mode verbeux

Exemples

Créer un VG "test_vg" utilisant les volumes physiques /dev/sdk1 et /dev/sdl1 avec une taille d'extents physique par défaut de 4Mio
vgcreate test_vg /dev/sdk1 /dev/sdl1
^
24 mai 2016

htmlpdflatexmanmd




vgdisplay

vgdisplay

Affiche les attributs des volume group

   vgdisplay permet de voir les attributs des volumes group avec ses volumes logiques et physique et leur taille. vgs est une alternative qui fournis les même informations dans le style de ps.

OPTIONS

-A|--activevolumegroups Ne sélectionne que les volumes groupe actifs. Le volume group est considéré actif si au moins un de ses volume logique est actif.
-c|--colon Affiche la sortie en colonne.
--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-s|--short Donne un listing court affichant l'existance du volume group
-S|--select Selection Affiche seulement les lignes qui matchent le critère donné
-v|--verbose Mode verbeux
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
--ignorelockingfailure Permet de traiter des opérations de métadonnées lecture-seule même si le module de lock échoue. Utile dans un script init si le répertoire de lock est monté en lecture seul
--ignoreskippedcluster Permet de quitter avec un status non-zero si la commande est lancé sans lockup clusterisé et que certains vg clusterisés doivent être ignorés
--nosuffix Supprime le suffixe pour les tailles. Utiliser avec --units si besoin
-P|--partial Fait de son mieux pour fournir un accès aux volumes group qui sont seulement disponible partiellement
--units hHbBsSkKmMgGtTpPeE Toutes les tailles affichée sont exprimé avec l'unité spécifiée.
-C|--columns Sortie séparée par des ':'
--aligned Utiliser avec --separator pour aligner les colonnes de sortie
--binary Utilise les valeurs binaire 0 ou 1 au lieu des valeurs littérales pour les colonnes qui ont exactement 2 valeurs valides
--noheadings Supprime les lignes d'en-tête
-o|--options [+|-|#]Field1[,Field2...] Liste de colonnes à afficher (-) ou enlever (-). '#' compacte les colonnes données. gv_all sélectionne toutes les colonnes de volume group.
-O|--sort [+|-]Key1[,[+|-]Key2...] Liste de colonnes pour l'ordre de trie.
--separator Separator Chaîne à utiliser pour séparer chaque colonne
--unbuffered Produit une sortie immédiatement sant trier ou aligner les colonnes
^
23 mai 2016

htmlpdflatexmanmd




vgexport

vgexport

Créer des volumes inconnus du système

   vgexport permet de créer des Volumes Group inactifs inconnus du système. Il permet ainsi de déplacer tous les volumes physiques dans ce VG vert un système différent pour un import ultérieur (vgimport). La plupart des outils LVM2 ignorent les VG exportés. vgexport efface l'ID système et vgimport le définis.

OPTIONS

-a, --all Exporte tous les VG inactifs
--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-S|--select Selection Affiche seulement les lignes qui matchent le critère donné
-v|--verbose Mode verbeux
^
06 juin 2016

htmlpdflatexmanmd




vgextend

vgextend

Ajouter des volumes physiques à un groupe de volume

   vgextend permet d'ajouter des volumes physiques à des volumes groupe pour l'étendre. De plus, il permet de ré-ajouter un volume physique qui était manquant dû à une erreur.

   Si le chemin du périphérique physique n'a pas été précédemment configuré pour LVM avec pvcreate, le périphérique est initialisé avec les même valeurs par défaut qu'utilisées par pvcreate. Si d'autres valeurs sont souhaitées, elles peuvent être données sur la ligne de commande avec les même options de pvcreate. Noter que les options de restauration ne sont pas disponibles. Si une opération de restauration est nécessaire, utilise pvcreate et vgcfgrestore.

OPTIONS

-A|--autobackup {y|n} Backup automatiquement les métadonnées après un changement
--command-profile ProfileName Sélectionne le profile de configuration de commande à utiliser
--restoremissing Permet de réajouter un volume physique sans le ré-initialiser
-f|--force Ne demande pas confirmation
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-t|--test Lance en mode test
-v|--verbose Mode verbeux

Options d'initialisation du périphérique

   Les options de suivis sont disponible pour l'initialisation des périphériques physique dans le volume groupe.

-f, --force Ne demande pas confirmation
-y, --yes Répond oui à toutes les questions
-Z, --zero {y|n} Spécifie les 4 premiers secteurs (2048octets) du périphérique devraient être supprimés
--labelsector sector Permet d'utiliser un secteur différent près du début du disque (entre 0 et 3) où placer l'identifiant LVM2 du PV
--metadatasize size Quantité d'espace approximative d'espace à définir pour chaque zone de métadonnée (la taille peut être arrondie)
--metadataignore {y|n} Ignore les zones de métadonnée sur le volume physique
--pvmetadatacopies copies Nombre de zones de métadonnées à définir dans chaque PV (0, 1 ou 2)
--dataalignment alignment Aligne le début des données à un multiple de ce nombre.
--dataalignmentoffset alignment_offset Décale de début de la zone de données par l'offset spécifié

Exemples

Étendre le volume group vg00 en ajoutant /dev/sda4 et /dev/sdn1
vgextend vg00 /dev/sda4 /dev/sdn1
^
23 mai 2016

htmlpdflatexmanmd




vgimport

vgimport

les volumes group exportés sont connus du système

   vgimport permet de créer un volume group qui a été précédemment exportés avec vgexport et les rend connus du système. vgexport supprime l'ID système VG et vgimport de définis.

OPTIONS

-a, --all importe tous les VG exportés
--force Importe les VG exportés même s'il y a des volumes physique manquant.
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-S|--select Selection Affiche seulement les lignes qui matchent le critère donné
-v|--verbose Mode verbeux
^
23 mai 2016

htmlpdflatexmanmd




vgimportclone

vgimportclone

importe et renomme des volumes group dupliqués

   vgimportclone est utilisé pour importer un VG dupliqué (ex: un snapshot hardware). Les VG et PV dupliqués ne peuvent pas être utilisés tant qu'ils ne peuvent pas coexister avec les VG et PV d'origine. vgimportclone renome le VG associé avec les PV spécifiés et change les uuid de VG et PV associés.

OPTIONS

-n, --basevgname VolumeGroupName Par défaut le snapshot VG sera renommé au nom original + un suffixe numérique. Cette option spécifie un autre nom.
-i, --import Importe les VG exportés. Sinon les VG qui ont été exporté ne seront pas changés (ni leur PV associés)

Variables d'environnement

LVM_BINARY Le binaire LVM2 à utiliser. Défaut: lvm

Exemples

le VG d'origine vg00 a les PV d'origine /dev/sda et /dev/sdb, et les snapshots respectifs sont /dev/sdc et /dev/sdd. Pour renommer le VG associé en vg00_snap:
vgimportclone --basevgname vg00_snap /dev/sdc /dev/sdd
^
23 mai 2016

htmlpdflatexmanmd




vgmerge

vgmerge

fusionne 2 volumes groupes

   Le second volume group spécifié inactif sera fusionné dans le premier si la taille d'extent physique sont identiques et que les sommaires de volume physique et logique des 2 volumes groupe rentrent dans les limites.

OPTIONS

-l, --list Affiche le volume fusionné comme vgdisplay -v
-t, --test Fait un test sans effecter de changement
-A|--autobackup {y|n} Backup automatiquement les métadonnées après un changement
--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-d|--debug définis le niveau de débug, de 1 à 6 fois pour augmenter les détails.è
-v|--verbose Mode verbeux

Exemples

fusionne le volume inactif 'my_vg' dans le volume group 'database':
vgmerge -v databases my_vg
^
23 mai 2016

htmlpdflatexmanmd




vgmknodes

vgmknodes

recréé un répertoire VG et les fichiers spéciaux LV

   Vérifie les fichiers spéciaux LVM2 dans /dev qui sont nécessaire pour les volumes logiques actifs et créé ceux qui manque et supprime ceux inutilisés.

OPTIONS

--refresh Si un volume logique dans le volume group est actif, recharge ses métadonnées. Ce n'est pas nécessaire dans une opération normale, mais est utile si quelque-chose ne va pas ou en faisant un cluster manuellement.
--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-v|--verbose Mode verbeux
^
23 mai 2016

htmlpdflatexmanmd




vgreduce

vgreduce

Réduire un volume group

   vgreduce permet de supprimer un ou plusieurs volumes physiques non-utilisés d'un volume group

OPTIONS

-a|--all Supprime tous les volume physiques vide si aucun n'est donné sur la ligne de commande
-A|--autobackup {y|n} Backup automatiquement les métadonnées après un changement
--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
--removemissing Supprime tous les volumes physique manquant du volume group, s'il n'y a pas de volumes logique alloué dessus. Cela permet de retourner en mode d'opération normal pour le volume group.
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-t|--test Lance en mode test
-v|--verbose Mode verbeux

   S'il n'est pas possible de spécifier les volumes physiques manquant avec --removemissing et qu'on ne peut/veut pas les supprimer manuellement, on peut lancer cette option avec --force pour supprimer tous LV partiel.

  Tous volumes logique et snapshots dépendants qui font partie de disques manquant sont supprimés completement. Cela inclus ces parties qui sont présent sur les disques qui sont présents.

  Si vos volumes logiques sont répartis sur de nombreux disques incluant ceux qui sont perdus, vous pourriez souhaiter essayer de sauver les données en activant les volumes logiques avec --partial.
^
23 mai 2016

htmlpdflatexmanmd




vgremove

vgremove

Supprimer un volume group

   vgremove permet de supprimer un ou plusieurs volume group. Si un ou plusieurs volumes physiques dans le volume group sont perdus, utiliser vgreduce --removemissing pour recréer une consistance des métadonnées. S'il y a des volumes logique qui existent dans le volume group, un confirmation est demandée.

OPTIONS

-f, --force Force la suppression de la confirmation si des LV existent dans le VG
--noudevsync Désactive la synchronisation udev. Le processus n'attend pas de notification udev.
--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-f|--force Ne demande pas confirmation
--noudevsync Désactive la synchronisation udev. Le processus n'attend pas de notification udev.
-S|--select Selection Ne traite que les lignes qui matchent le critère donné
-t|--test Lance en mode test
-v|--verbose Mode verbeux
^
23 mai 2016

htmlpdflatexmanmd




vgrename

vgrename

Renommer un volume group

   vgrename renomme un volume group existant. Tous les volumes group visible au système doivent avoir un nom différent. Sinom de nombreuses commandes LVM2 vont refuser de fonctionner.

OPTIONS

-A|--autobackup {y|n} Backup automatiquement les métadonnées après un changement
--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-t|--test Lance en mode test
-v|--verbose Mode verbeux

Exemples

Renomme le volume group vg02 en my_volume_group:
vgrename /dev/vg02 /dev/my_volume_group
ou
vgrename vg02 my_volume_group
Changer le nom du volume group avec un uuid en VolGroup00_tmp
vgrename Zvlifi-Ep3t-e0Ng-U42h-o0ye-KHu1-nl7Ns4 VolGroup00_tmp
^
24 mai 2016

htmlpdflatexmanmd




vgs

vgs

Affiche des informations sur les volumes group

OPTIONS

--all Inclus tous les volumes group
--aligned Utiliser avec --separator pour aligner les colonnes de sortie
--binary Utilise les valeurs binaire 0 ou 1 au lieu des valeurs littérales pour les colonnes qui ont exactement 2 valeurs valides
--nameprefixes Ajoute un préfixe LVM2_ plus le nom du champ dans la sortie. Utile avec --neheadings pour produire une liste de paires champ=valeur qui peuvent être utilisées en variable d'environnement.
--noheadings Supprime les lignes d'en-tête
--nosuffix Supprime le suffixe pour les tailles. Utiliser avec --units si besoin
-o|--options [+|-|#]Field[,Field...] Liste de colonnes à afficher (-) ou enlever (-). '#' compacte les colonnes données. gv_all sélectionne toutes les colonnes de volume group.
-O|--sort [+|-]Key1[,[+|-]Key2...] Liste de colonnes pour l'ordre de trie.
-S|--select Selection Affiche seulement les lignes qui matchent le critère donné
--separator Separator Chaîne à utiliser pour séparer chaque colonne
--unbuffered Produit une sortie immédiatement sant trier ou aligner les colonnes
--units hHbBsSkKmMgGtTpPeE Toutes les tailles affichée sont exprimé avec l'unité spécifiée.
--unquoted avec --nameprefixes, affiche les valeurs sans guillemets
-v|--verbose Mode verbeux
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-P|--partial Fait de son mieux pour fournir un accès aux volumes group qui sont seulement disponible partiellement
--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
--ignorelockingfailure Permet de traiter des opérations de métadonnées lecture-seule même si le module de lock échoue. Utile dans un script init si le répertoire de lock est monté en lecture seul
--ignoreskippedcluster Permet de quitter avec un status non-zero si la commande est lancé sans lockup clusterisé et que certains vg clusterisés doivent être ignorés
--rows Affiche les colonnes brutes
^
23 mai 2016

htmlpdflatexmanmd




vgscan

vgscan

Scanne tous les disques à la recherche des volumes group et reconstruit les caches

   vgscan scanne tous les disques SCSI, (E)IDE, md et d'autres types de disques dans le système à la recherche de volumes physiques LVM et de volumes groupe. Définir un filtre dans lvm.conf pour restreindre le scanne et éviter un cd-rom par exemple. Dans LVM2, vgscan est automatique, mais il peut être nécessaire de le lancer après un changement hardware.

OPTIONS

--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-v|--verbose Mode verbeux
--ignorelockingfailure Permet de traiter des opérations de métadonnées lecture-seule même si le module de lock échoue. Utile dans un script init si le répertoire de lock est monté en lecture seul
--mknodes Vérifie également le fichiers spéciaux LVM dans /dev qui sont nécessaires pour les volumes logiques actifs et créé tous ceux qui manques et supprime ceux non-nécessaire
--notifydbus Envoie une notification à d-bus
-P|--partial Fait de son mieux pour fournir un accès aux volumes group qui sont seulement disponible partiellement
--cache scanne le périphériques à la recherche de volumes physique et de volume groupe et instruit lvmetad de mettre à jours son état en cache en fonction.
^
08 juin 2016

htmlpdflatexmanmd




vgsplit

vgsplit

split un volume group en 2

   vgsplit déplace un ou plusieurs volumes physique depuis un VG vers un autre. Le volume physque déplacé explicitement ou implicitement avec -n ‹lvname›, auquel cas seules les PV sous-jacents au LV spécifié seront déplacés.

   Si le VG de destination n'existe pas, un nouveau volume group est créé. Les attributs par défaut peuvent être spécifiés avec --alloc, --clustered, --maxlogicalvolumes, --metadatatype, --maxphysicalvolumes et --[vg]metadatacopies. Si une de ces options n'est pas spécifiée, sa valeur est prise du VG source. Si un type de métadonnée non-lvm2 (ex: lvm1) est utilisé, il faut utiliser l'option -M pour spécifier le type de métadonnées directement.

   Si le VG de destination existe, il est vérifié pour sa compatibilité avec le VG source avant que les volumes physiques soient déplacés. Les volumes logiques ne peuvent pas être splittés entre les volumes groupe. vgsplit ne déplace que les volumes physiques complet. Utiliser pvmove si nécessaire. un vgsplit dans un VG existant garde la valeur vgmetadatacopies du VG existant. Utiliser vgchange pour changer cette valeur.

   Les volumes logique ne peuvent pas être splittés entre les volumes groups, vgsplit ne déplace que les volumes physiques complet: Pour déplacer une partie d'un volume physique, utiliser pvmove. Chaque volume logique existant doit être entièrement sur les volumes physique formant soit la source soit la destination. Pour cette raison, vgsplit peut échouer avec une erreur si un split résulte en un volume logique splité entre les volumes groupe.

   Un vgsplit en un vg existant retient la valeur du vg existant de vgmetadatacopies. Pour changer la valeur de vgmetadatacopies, utiliser vgchange.

OPTIONS

--alloc AllocationPolicy Sélectionne la stratégie d'allocation (anywhere|contiguous|cling|inherit|normal)
-A|--autobackup {y|n} Backup automatiquement les métadonnées après un changement
-c|--clustered {y|n} Si le locking est activé, est à yes par défaut, indiquant que ce volume group est partagé avec d'autres nœuds dans le cluster.
--commandprofile ProfileName Sélectionne le profile de configuration de commande à utiliser
-l|--maxlogicalvolumes MaxLogicalVolumes Définis le nombre maximum de LV du VG
-M|--metadatatype type Spécifie quel type de métadonnée utiliser
-p|--maxphysicalvolumes MaxPhysicalVolumes Définis le nombre maximum de volumes physiques qui peuvent appartenir à ce volume group. 0 = illimité
--[vg]metadatacopies NumberOfCopies|unmanaged|all Définis le nombre de copies de métadonnées dans le volume group. à une valeur autre que 0, lvm gère automatiquement le flag 'metadataignore' dans les volumes physique pour obtenir le nombre de copies des métadonnées. 'unmanaged', lvm ne gère pas automatiquement le flag. 'all', lvm efface tous les flags dans toutes les zones de métadonnées dans le vg, puis passe en unmanaged.
-n|--name LogicalVolumeName Spécifie le nom du volume logique au lieu du chemin du volume physique (seuls les volumes physiques sous le LV spécifié sont déplacés)
-d|--debug Définis le niveau de débug, de 1 à 6 fois pour augmenter les détails
-t|--test Lance en mode test
-v|--verbose Mode verbeux
^
16 janvier 2015

htmlpdflatexmanmd




zdb

zdb

Debugger ZFS

Description

   Cette commande est utilisée pour diagnostiquer les erreurs et autres statistiques. Vu que ZFS est toujours consistant su le disque et s'auto-répare, zdb devrait seulement être lancé sous la direction d'un ingénieur. Sans argument, zdb effectue une vérification de consistance dans le pool et les datasets associés, et reporte tout problème détecté. Les options sont interne à Sun et sont sujets à changement.

Codes de sortie

0 Le pool est consistant
1 Une erreur a été détectée
2 Options de ligne de commande invalides.

attributs

attribute type_______-_attribute value
Availability_________-____SUNWzfsu
Interface Stability _-____Unstable

^
25 janvier 2015

htmlpdflatexmanmd




zfs

zfs

Configure des systèmes de fichiers ZFS

Description

   La commande zfs configure des datasets ZFS dans des pools de stockage ZFS. Un dataset est identifié par un chemin unique dans l'espace de nom ZFS. par exemple pool/{filesystem,volume,snapshot} où la longueur maximum d'un nom de dataset est MAXNAMELEN (256octets). Un dataset peut être un des suivants:

filesystem Un dataset ZFS de type filesystem peut être monté dans l'espace de nom système standard et fonctionne comme tout autre système de fichier. Bien que les système de fichiers ZFS sont conçus pour être conforme POSIX, des problème connus existent qui empêche la conformité dans certains cas. Les applications qui dépendent des conformités standard peut échouer lors de la vérification de l'espace disque disponible.
volume Un volume logique exporté comme périphérique block ou brute. Ce type de dataset devrait seulement être utilisé sous des circonstances particulière. Les systèmes de fichier sont typiquement utilisé dans la plupart des environnements.
snapshot Une version lecture seul d'un filesystem ou volume à un point donné dans le temps. C'est spécifié en filesystem@name ou volume@name.

Hiérarchie des systèmes de fichier

   Un pool de stockage ZFS est une collection logique de périphériques qui fournissent de l'espace pour les datasets. Un pool de stockage est également la racine de la hiérarchie de système de fichiers ZFS. La racine du pool peut être accédé comme système de fichier, tel que monter et démonter, prendre des snapshots, et définir des propriétés. Les caractéristiques de stockage physique, cependant, sont gérés par la commande zpool.

Snapshots

   Un snapshot est une copie lecture seul d'un système de fichier ou un volume. Les snapshots peuvent être crées extrêment rapidement, et ne consomment initialement aucun espace dans le pool. Comme les données dans le dataset actif changent, le snapshot consomme plus de données et qui sont partagés avec le dataset actif. Les snapshots peuvent avoir des noms arbitraires. Les snapshots de volumes peut être clonés ou annulés, mais ne peuvent pas être accédés indépendamment.

   Les snapshots de filesystem peuvent être accédés sous le répertoire .zfs/snapshot dans le système de fichier racine. Les snapshots sont automatiquement montés à la demande et peuvent être démontés à intervalles réguliers. La visibilité du répertoire .zfs peut être contrôlé par la propriété snapdir.

Clones

   Un clone est un volume en écriture ou un système de fichier dont le contenu initial est le même qu'un autre dataset. Comme avec les snapshots, créer un clone est presque instantané, et ne consomme pas d'espace disque initialement.

   Les clones peuvent seulement être créés depuis un snapshot. Quand un snapshot est cloné, il créé une dépendance implicit entre le parent et l'enfant. Même quand un clone est créé ailleurs dans la hiérarchie de dataset, le snapshot original ne peut pas être détruit tant qu'un clone existe. La propriété origin expose cette dépendance, et la commande destroy liste de telles dépendances, si elles existent.

   La relation de dépendance des parent/enfant des clones peut être renversé en utilisant la sous-commande promote. Le système de fichier "origin" devient un clone du système de fichier spécifié, qui rend possible de détruire le système de fichier depuis lequel le clone avait été créé.

Points de montage

   Créer un système de fichier ZFS est une opération simple, donc le nombre de systèmes de fichier par système est susceptible d'être nombreux. Pour faire face à cela, ZFS gère automatiquement le montage et le démontage des systèmes de fichiers sans avoir besoin d'éditer /etc/vfstab. Tous les systèmes de fichiers gérés automatiquement sont montés par ZFS au boot.

   Par défaut, les systèmes de fichiers sont montés sous /path, où path est le nom du système de fichier dans l'espace de nom ZFS. Les répertoires sont créés et détruis si nécessaires.

   Un système de fichier peut également avoir un point de montage dans la propriété mountpoint. Ce répertoire est créé si nécessaire, et ZFS monte automatiquement le système de fichier quand zfs mount -a est invoqué (sans éditer /etc/vfstab). mountpoint peut être hérité, donc si pool/home a un point de montage de /export/stuff, alors le pool/home/user hérite automatiquement d'un point de montage /export/stuff/user.

   Une propriété mountpoint de système de fichier à none empêche le système de fichier d'être monté. Si nécessaire, les systèmes de fichiers ZFS peuvent également être gérés avec les outils traditionnels. Si un point de montage de système de fichier est mis à legacy, ZFS ne tente pas de gérer le système de fichier.

Zones

   Un système de fichiers ZFS peut être ajouté à une zone non-globale en utilisant la sous-commande zonecfg add fs. Un système de fichier ZFS qui est ajouté à une zone non-globale doit avoir sa propriété mountpoint à legacy.

   Les propriétés physiques d'un système de fichier ajouté sont contrôlé par l'administrateur global. Cependant, l'administrateur de zone peut créer, modifie, ou détruire des fichiers dans le système de fichier ajouté, en fonction de la manière dont le système de fichier est monté.

   Un dataset peut également être délégué dans une zone non-globale en utilisant la sous-commande zonecfg add dataset. Vous ne pouvez pas déléguer un dataset à une zone et l'enfant du même dataset à une autre zone. L'administrateur de zone peut changer les propriétés du dataset ou un de ses enfant. Cependant, la propriété quota est contrôlée par l'administrateur global.

   Un volume ZFS peut être ajouté comme périphérique à une zone non-globale en utilisant la sous-commande zonecfg add device. Cependant, ses propriétés physiques peuvent être modifiées seulement par l'administrateur global.

   Après qu'un dataset est délégué à une zone non-globale, la propriété zoned est automatiquement définie. Un système de fichier zoned ne peut pas être monté dans la zone globale, vu que l'administrateur de zone peut avoir définis le point de montage à des valeurs inacceptables.

   L'administrateur global peut effacer la propriété zoned, bien que cela devrait être fait avec une extrême attention. L'administrateur global devrait vérifier que tous les points de montage sont acceptable avant d'effacer cette propriété.

Déduplication

   La déduplication est un processus pour supprimer les données redondantes au niveau block, réduisant la quantité globale de données stockée. Si un système de fichier a la propriété dedup, les blocks de données dupliqués sont supprimés de manière synchrone. Le résultat est que seul une donnée unique est stockée et les composants communs sont partagés entre les fichiers.

Propriétés natives

   Les propriétés sont divisées en 2 types, les propriétés natives et les propriétés définis par l'utilisateur ( user ). Les propriétés natives exportent des statistiques internes ou contrôle le fonctionnement de ZFS. En plus, les propriétés natives sont soit éditables, soit lecture-seul. Les propriété user n'ont pas d'effet sur le fonctionnement de ZFS, mais peuvent être utilisés pour annoter les datasets d'une manière significative dans l'environnement.

   Tout dataset a un jeu de propriété qui exporte des statistiques sur le dataset aussi bien que contrôles divers modes. Les propriétés sont hérités du parent sauf s'ils sont spécifiés dans l'enfant. Certaines propriétés s'appliquent uniquement à certains type de datasets.

   Les valeurs des propriétés numériques peuvent être spécifié en utilisant des suffixes human-readable (ex: k, KB, M, Gb, etc.). Les valeurs de propriétés non-numériques sont sensibles à la casse et doivent être en minuscule, sauf pour mountpont, sharenfs, et sharesmb.

   Les propriétés natives suivantes consistent de statistiques lecture-seules sur le dataset. Ces propriétés ne peuvent être ni des jeux, ni hérités. Les propriétés natives s'appliquent à tous les types de dataset sauf mention contraire.

available La quantité d'espace disponible dans le dataset et tous ses enfants, assumant qu'il n'y a pas d'autre activité dans le pool. Parce que l'espace est partagé dans le pool, la disponibilité peut être limité par plusieurs facteurs, incluant la taille physique du pool, quotas, reservations, ou d'autres datasets dans le pool.
compressratio Le ratio de compression pour ce dataset, exprimé en multiplicateur. La compression peut être activée avec zfs set compression=on. Défaut: off.
creation La date de création du dataset
defer_destroy Cette propriété est on si le snapshot a été marqué pour une destruction déférée en utilisant la commande zfs destroy -d. Sinon, la propriété est off.
origin Pour les systèmes de fichier ou les volumes clonés, le snapshot depuis lequel le clone a été créé. L'origine ne peut pas être supprimé tant qu'un clone existe.
referenced La quantité de donnée qui est accessible par ce dataset, qui peut être partagé ou non avec d'autre datasets dans le pool. Quan un snapshot ou un clone est créé, il référence initialement la même quantité d'espace que le système de fichier ou le snapshot depuis lequel il a été créé, vu que son contenu est identique.
type le type de dataset: filesystem, volume, ou snapshot
used La quantité d'espace disque consommé par ce dataset et tous ses descendants. C'est la valeur qui est comparée au quota et à la réservation du dataset. L'espace utilisé n'inclus pas cette réservation du dataset, mais prend en compte les réservations de tous les dataset descendants. La quantité d'espace qu'un dataset consomme depuis son parent, aussi bien que la quantité d'espace qui sont libérés si ce dataset est détruit récursivement, est supérieur à son espace utilisé et sa réservation.

   Quand des snapshots sont créés, leur espace est initialement partagé entre le snapshot et le système de fichier, et possiblement avec les snapshots précédents. Vu que le système de fichier change, l'espace qui a été précédemment partagé devient unique au snapshot, et compté dans l'espace utilisé du snapshot. Additionnellement, supprimer les snapshots peut augmenter la quantité d'espace unique à ( et utilisé par ) d'autre shapshots.

   La quantité d'espace utilisé, disponible, ou référencé ne prend pas en compte les changements en attente, Ces changements en attente sont généralement pris en comptes dans les secondes qui suivent. Envoyer un changement au disque avec fsync ou O_SYNC ne garantit pas nécessairement que les informations d'utilisation de l'espace est mis à jours immédiatement.

usedby*  Les propriétés usedby* décomposent les propriétés used dans les diverses raisons pour lequel l'espace est uilisé. Spécifiquement, used = usedbychildren + usedbydataset + usedbyrefreservation +, usedbysnapshots. Ces propriétés sont seulement disponible pour les datasets créés dans des pools version 13.
usedbychildren La quantité d'espace utilisé par l'enfant de ce dataset, qui serait libéré si tous le dataset de l'enfant était détruit.
usedbydataset La quantité de l'espace utilisé par ce dataset lui-même, qui serait libéré si le dataset était détruit.
usedbyrefreservation La quantité d'espace utilisé par un refreservation définis dans ce dataset, qui serait libéré si refreservation était supprimé.
usedbysnapshots La quantité d'espace consommé par les snapshots de ce dataset. En particulier, c'est la quantité d'espace qui aurait été libéré si tous les snapshots de ce dataset étaient supprimés. Noter que ce n'est pas simplement la somme des propriétés used des snaphots parce que l'espace peut être partagé par plusieurs snapshots.
userused@user La quantité d'espace consommé par l'utilisateur spécifié dans ce dataset. L'espace est calculé pour le propriétaire de chaque fichier, tel qu'affiché par ls -l. La quantité d'espace est affiché par du et ls -s.

   Les utilisateurs non-privilégiés peuvent accéder seulement à leur propre espace. L'utilisateur root, ou un utilisateur qui a obtenu le privilège userused avec zfs allow, peut accéder à l'utilisation de tout le monde.

   userused@... n'est pas affiché par zfs get all. Le nom de l'utilisateur doit être ajouté après les @, en utilisant un des formes suivantes:

        - Nom POSIX ( ex: joe )
        - ID numérique POSIX (ex: 789)
        - Nom SID (ex: joe.smith@mydomain)
        - ID numérique SID (ex: S-1-123-456-789)

userrefs Cette propriété est définie au nombre d'utilisateurs dans ce snapshot, définis par la commande zfs hold.
groupused@group La quantité d'espace consommée par le groupe spécifié dans ce dataset. L'espace est calculé au groupe de chaque fichier, comme affiché par la commande ls -l. Les utilisateurs non-privilégiés peuvent seulement accéder à l'espace de leur propre groupe. L'utilisateur root, ou un utilisateur qui a obtenu le privilège groupused peuvent accéder à l'utilisation de tous les groupes.
volblocksize=blocksize Pour les volumes, spécifie la taille de block du volume. blocksize en peut pas être changé une fois le volume écrit, donc il doit être définis à la création. Défaut: 8Koctets. Tout puissance de 2 de 512o à 128Ko sont valides.

   Les propriété natives suivantes peuvent être utilisée pour changer le comportement d'un dataset:

aclinherit=discard | noallow | restricted | passthrough | passthrough-x Contrôle comment les entrées d'ACL sont hérités quand des fichiers et des répertoires sont créés. Un système de fichier avec une propriété aclinherit à discard n'hérite d'aucune entrée ACL. Un système de fichier avec une propriété aclinherit à noallow hérite uniquement des ACL héritables qui spécifient des permissions "deny". La valeur "restricted" (le défaut) supprime les permissions write_acl et write_owner quand l'entrée d'ACL est héritée. Un système de fichier avec une propriété aclinherit à passthrough hérite de toutes les entrées d'ACL héritables sans modification. passthrough-x à la même signification, excepté que les ACE owner@, group@ et everyone@ héritent des permissions d'exécution uniquement si le mode de création de fichier demande également le bit d'exécution.

   Quand la valeur de propriété est définie à passthrough les fichiers sont créés avec un mode déterminé par les ACE héritables. Si aucune ACE héritable n'existe qui affecte ce mode, alors le mode est définis en accord avec le mode demandé depuis l'application.

aclmode=discard | groupmask | passthrough Contrôle comment une ACL est modifiée durant un chmod. Un système de fichier avec une propriété aclmode à discard supprime toutes les entrées ACL qui ne représentent pas le mode du fichier. Une propriété aclmode a groupmask (le défaut) réduit les permissions utilisateur ou groupe. Les permission sont réduit, tel qu'ils ne sont pas supérieurs que les bits de permissions du groupe, sauf si c'est une entrée utilisateur qui a le même UID que le propriétaire du fichier ou répertoire. Dans ce cas, les permissions d'ACL sont réduites pour qu'elle ne soient pas supérieurs aux bits de permission du propriétaire. Un système de fichier avec une propriété aclmode à passthrough indique qu'aucun changement n'est fait aux ACL autre que générer les entrées ACL nécessaires pour représenter le nouveau mode du fichier ou répertoire.
atime=on | off Contrôle si la date d'accès pour les fichiers est mis à jours quand ils sont lus. Désactiver cette propriété évite de produire du trafic d'écriture en lisant des fichiers et peut augmenter les performances d'écritures. Défaut: on.
canmount=on | off | noauto À off, le système de fichier ne peut pas être monté, et est ignoré par zfs mount -a. C'est similaire à définir mountpoint à none, excepté que le dataset aura une propriété mountpoint définie, qui peut être hérité. Définir cette propriété à off permet aux datasets d'être utilisé seulement comme mécanisme d'héritage de propriété. Un exemple est d'avoir 2 datasets avec le même nountpoint, donc l'enfant des 2 datasets apparaît dans le même répertoire, mais peut avoir des caractéristiques hérités différents.

   Quand l'option noauto est définis, un dataset peut seulement être monté de démonté explicitement. Le dataset n'est pas monté automatiquement quand le dataset est créé ou importé, ni n'est monté par zfs mount -a ou démonté par zfs umount -a. Cette propriété n'est pas héritée.

checksum=on | off | fletcher2,| fletcher4 | sha256 Contrôle le checksum utilisé pour vérifier l'intégrité des données. La valeur par défaut est on, qui sélectionne automatiquement un algorithme approprié ( actuellement, fletcher4). Changer cette propriété n'affecte que les données nouvellement écrites.
compression=on | off | lzjb | gzip | gzip-N | zle Contrôle l'algorithme de compression utilisé pour ce dataset. L'algorithme lzjb est optimisé pour les performances tout en proposant un taux de compression correct. on équivaut à lzjb. Changer cette propriété n'affecte que les données nouvellement écrites.
copies=1 | 2 | 3 Contrôle le nombre de copies de données stockées pour ce dataset. Ces copies sont en plus de toute redondances fournies par le pool. Les copies sont stockée sur différents disques, si possible. Changer cette propriété n'affecte que les données nouvellement écrites. Cependant, définir cette propriété à la création du système de fichier en utilisant l'option -o copies=N
dedup=on | off | verify | sha256[,verify] Contrôle si la déduplication est en effet pour un dataset. Défaut: off. Le checksum utilisé pour la déduplication est sha256. Quand activé, l'algorithme de checksum écrase la propriété checksum. Définir la valeur à verify est équivalent à spécifier sha256,verify. À verify, quand 2 blocks ont la même signature, ZFS fait une comparaison supplémentaire bit à bit.
devices=on | off Contrôle si les périphérique peuvent être ouvert dans ce système de fichier. Défaut: on.
exec=on | off Contrôle si les processus peuvent être exécutés depuis ce système de fichier. Défaut: on.
mlslabel=label | none Label de sensibilité qui détermine si un dataset peut être monté dans une zone dans le système avec Trusted Extensions activé. Si le dataset labelisé correspond à la zone labelisée, la dataset peut être monté et accédé depuis la zone labélisée.

   Quand cette propriété n'est pas définie, la valeur par défaut est none. Définir à none est équivalent à supprimer cette propriété.

   Cette propriété peut être modifiée seulement quand Trusted Extensions est activé et seulement avec les privilèges appropriés. Les droits de le modifier ne peut pas être délégué. En changeant un label à un label supérieur ou en définissant le label initial, le privilège {PRIV_FILE_UPGRADE_SL} est requis. En changeant un label à un label inférieur ou à none, le privilège {PRIV_FILE_DOWNGRADE_SL} est requis. Changer le dataset à des labels autre que none peut être fait seulement quand le dataset n'est pas monté. Quand un dataset avec le label none est monté dans une zone labélisée, l'opération de montage définis automatiquement le mlslabel au label de cette zone.

mountpoint=path | none | legacy Contrôle le point de montage utilisé pour ce système de fichier. quand mountpoint est changé pour un système de fichier, le système de fichier et ses enfants qui héritent du point de montage sont démontés. Si la nouvelle valeur est legacy, alors ils restent démontés. Sinon, ils sont automatiquement remontés dans le nouvel emplacement si la propriété était précédemment legacy ou none, ou s'ils étaient montés avant que la propriété a été changée. En plus, tous système de fichiers partagé sont départagés et partagés dans le nouvel emplacement.
nbmand=on | off Contrôle si le système de fichier devrait être monté avec nbmant (Non Blocking mandatory locks). C'est utilisé pour les clients CIFS. Changer cette propriété prend effet seulement quand le système de fichier est démonté et remonté.
primarycache=all | none | metadata Contrôle ce qui est caché dans le cache primaire (ARC). Si cette propriété est à all, les données utilisateur et les métadonnées sont cachées. Si cette propriété est à none, rien n'est caché. Si cette propriété est définie à metadate, seul les metadate sont cachés. Défaut: all.
quota=size | none Limite la quantité d'espace qu'un dataset et ses descendants peuvent consommer. Cette propriété force une limite hard dans la quantité d'espace utilisée. Cela inclus tout l'espace consommé par ses descendants, incluant les systèmes de fichiers et les snapshots. Définir un quota dans un descendant d'un dataset qui a déjà un quota n'écrase par le quota de l'ancêtre, mais impose une limite additionnelle. Les quota ne peuvent pas être définis dans les volumes, vu que volsize agit comme quota implicite.
userquota@user=size | none Limite la quantité d'espace consommée par l'utilisateur spécifié. Similairement à la propriété refquota, le calcul de l'espace userquota n'inclus pas l'espace qui est utilisé par les datasets descendant, tel les snapshots et les clones. La consommation d'espace de l'utilisateur est identifié par la propriété userspace@suser.

   Forcer les quotas utilisateur peut être retardé de quelques secondes. Ce délai signifie qu'un utilisateur peut excéder son quota avec que le système notifie qu'il est hors quota. Le système va commencer à refuser les écritures additionnelles avec le message d'erreur EDQUOT.

   Les utilisateurs non-privilégiés peut seulement accéder à l'utilisation de l'espace de leur propre groupe. L'utilisateur root, ou un utilisateur qui a obtenu le privilège userquota avec zfs allow peut obtenir et définir le quota pour tout le monde.

   Cette propriété n'est pas disponible pour les volumes, et dans les systèmes de fichier avant v4 et les pools avant v15. Les propriétés userquota ne sont pas affichés par zfs get all. Le nom de l'utilisateur doit être ajouté après les @, en utilisant un des formes suivantes:

groupquota@group=size|none Limite la quantité d'espace consommé par le groupe spécifié.
readonly=on|off Contrôle si le dataset peut être modifié. Défaut: off.
recordsize=size Spécifie une taille de block suggérée pour les fichiers dans le système de fichier. Cette propriété est conçue pour être utilisé avec des bases de données qui accèdent à des enregistrement de taille fixe.
refquota=size|none Limite la quantité d'espace qu'un dataset peut consommer. Cette propriété force une limite hard sur la quantité d'espace utilisé. Cette limite n'inclue pas l'espace utilisé par les descendants, incluant les systèmes de fichier et les snapshot.
refreservation=size|none La quantité minimum d'espace garantit pour un dataset, n'incluant pas ses descendants. Quand la quantité d'espace utilisé est inférieur à cette valeur, le dataset est traité comme s'il prenait cette espace. Si refreservation est définis, un snapshot est seulement permis s'il y a suffisamment d'espace disponible dans le pool en dehors de cette réservation.
reservation=size|none Quantité minimum garantie pour un dataset et ses descendants. Quand la quantité d'espace utilise est inférieur à cette valeur, le dataset est traité comme s'il prenait cet espace.
secondarycache=all|none|metadata Contrôle ce qui est mis en cache secondaire (L2ARC). Si cette propriété est définie à all, les données utilisateurs et les métadonnées sont cachés.
setuid=on|off Contrôle si le bit set-uid est respecté pour le système de fichier. Défaut: on
shareiscsi=on|off Comme sharenfs, indique si un volume ZFS est exporté comme target iSCSI. Les valeurs peuvent être on, off, et type=disk. Défaut: off.
sharesmb=on|off|opts Contrôle si le système de fichier est partagé en utilisant le service Solaris CIFS, et quelles options sont utilisée.
sharenfs=on|off|opts Contrôle si le système de fichier est partagé via nfs, et quelles options sont utilisée. Un système de fichier avec la propriété sharenfs à off est géré via les outils traditionnels tel share, unshare, et dfstab. Sinon, le système de fichier est automatiquement partagé via zfs share et zfs unshare. Quand sharenfs est changé pour un dataset, le dataset et ses enfants héritant de la propriété sont partagés avec de nouvelles options, seulement si la propriété était précédemment off, ou s'il étaient partagés avant que la propriété soit changé.
logbias = latency | throughput Fournis une astuce à ZFS sur la manipulation des requêtes dans ce dataset. Si logbias est à latency (par défaut), ZFS utilise les périphériques de log du pool (si configuré) pour manipuler les requête à faible latence. À throughput, ZFS n'utilise pas les périphérique de log du pool. À la place, ZFS optimise les opérations synchrone pour le pool et l'utilisation efficace des ressources.
snapdir=hidden | visible Contrôle si le répertoire .zfs est caché ou visible dans le root du système de fichier. Défaut: hidden.
version=1 | 2 | current La version de ce système de fichier, qui est indépendant de la version du pool. Cette propriété peut seulement être définie pour les dernières versions supportées.
volsize=size Pour les volumes, spécifie la taille logique du volume. Par défaut, créer un volume établis une réservation de taille égale. Pour les pools de stockage avec un numéro de version 9 ou plus, un refreservation est définis à la place.
vscan=on | off Contrôle si les fichiers régulier devraient être scannés pour les virus quand un fichier est ouvert et fermé. En plus d'activer ce service, le service de scan de virus doit également être activé. Défaut: off.
xattr=on | off Contrôle si les attributs étendus sont activés pour ce système de fichier. Défaut: on
zoned=on | off Contrôle si le dataset est géré depuis une zone non-globale. Défaut: off.

   Les 3 propriétés suivantes ne peuvent pas être changée après la création du système de fichier. Si les propriétés ne sont pas définies avec les commandes zfs create et zpool create, ces propriété sont héritées du dataset parent.

casesensitivity=sensitive | insensitive | mixed Indique si l'algorithme de correspondance de nom de fichier utilisé par le système de fichier devrait être sensible à la casse.mixed indique que le système de fichier supporte les requêtes pour les 2 cas. Traditionnellement, les systèmes de fichiers UNIX et POSIX ont des noms de fichier sensible à la casse.
normalization = none | formC | formD | formKC | formKD Indique si le système de fichier devrait effectuer une normalisation unicode des noms de fichier quand 2 noms de fichier sont comparés. Si cette propriété est définie à une valeur autre que none et que la propriété utf8only n'est pas spécifiée, cette dernière est automatiquement mis à on. Défaut: none.
utf8only=on | off Indique si le système de fichier devrait rejeter les noms de fichier qui incluent des caractères qui ne sont pas présents dans le jeu UTF8.

Propriétés de point de montage temporaire

Quand un système de fichier est monté, soit via mount ou via zfs mount, ses options de montage sont définis en accord avec ses propriétés. La corrélation entre les propriété et les options de montage sont comme suit:
PROPERTY__________MOUNT OPTION
devices___________devices/nodevices
exec______________exec/noexec
readonly__________ro/rw
setuid____________setuid/nosetuid
xattr_____________xattr/noxattr

   En plus, ces options peuvent être définis sur une base par montage en utilisant l'option -o, sans affecter la propriété qui est stockée sur disque. Les valeurs spécifiées sur la ligne de commande écrasent celle stockées dans le dataset. L'option -nosuid est un alias pour nodevices,nosetuid.

Propriétés utilisateur

   En plus des propriétés natives standard, ZFS supporte les propriétés utilisateurs arbitraires. Les propriétés utilisateur n'ont pas d'effet sur le fonctionnement de ZFS, mais les applications et les administrateurs peut les utiliser pour annoter les datasets.

   Les noms de propriété utilisateur doivent contenir un caractère ':' pour les distinguer des propriétés natives. Ils peuvent contenis les lettre minuscules, des nombres, et les caractères: ':', '-', '.', '_'. La convention attendue est que le nom de propriété est divisée en 2 portions tel que module:property, mais cet espace de nom n'est pas forcé par ZFS. Les noms de propriété utilisateur ne peuvent pas avoir plus de 256 caractères, et ne peuvent pas commencer par un '-'.

   En utilisant des propriétés utilisateur, il est fortement suggéré d'utiliser reverse DNS pour le composant module pour réduire les chances que 2 packages indépendants utilisent le même nom de propriété pour différents buts. Les noms de propriété commençant avec com.sun. sont réservés.

   Les valeurs des propriétés utilisateur sont des chaînes arbitraires, sont toujours hérités, et ne sont jamais validées. Tous les commandes qui opèrent sur les propriétés peuvent être utilisé pour manipuler les propriétés utilisateurs également. Utiliser la commande zfs inherit pour supprimer des propriétés utilisateur. Si la propriété n'est pas définie dans un dataset parent, il est supprimé entièrement. Les valeur de propriétés sont limitées à 1024 caractères.

Volumes ZFS comme Swap ou périphériques de Dump

   Durant une installation initiale ou une mise à jours depuis un système de fichier UFS, un périphérique de swap et un périphérique de dump sont créés dans le pool root des volume ZFS. Par défaut, la taille de la zone de swap est basée sur la moitié de la mémoire physique jusqu'à 2Go. La taille du périphérique de dump dépend des prérequis du kernel à l'installation. Des volumes ZFS séparés doivent être utilisés pour les périphérique swap et dump. Ne pas swapper dans un fichier dans un système de fichier ZFS. Une configuration de fichier swap ZFS n'est pas supportée. Si vous devez changer votre zone de swap ou dump un fois le système installé, utiliser les commandes swap et dumpadm.

Sous Commandes

   Toutes les sous-commandes qui modifient l'état sont loggés de manière persistante dans le pool sous leur forme originelle.

zfs create [-p] [-o property=value] ... filesystem Crée un nouveau système de fichie zfs. Le système de fichier est automatiquement monté en accord avec les propriété mountpoint héritées du parent.

        -p Crée tous les datasets parent non-existant. les Datasets créés de cette manière sont automatiquement montés en accord avec le mountpoint hérité de leur parent. Toute propriété spécifié sur la ligne de commande est ignorée. Si le système de fichier cible existe déjà, l'opération se termine avec succès.
        -o property=value Définis la propriété spécifiée. Peut être spécifié plusieurs fois

zfs create [-ps] [-b blocksize] [-o property=value] ... -V size volume Crée un volume à la taille donnée. Le volume est exporté comme périphérique block dans /dev/zvol/{dsk,rdsk}/path, où path est le nom du volume dans l'espace de nom zfs. La taille représente la taille logique tel qu'exporté par le périphérique. Par défaut, une réservation de taille égal est créée.

        -p Crée tous les datasets parent non-existant. les Datasets créés de cette manière sont automatiquement montés en accord avec le mountpoint hérité de leur parent. Toute propriété spécifié sur la ligne de commande est ignorée. Si le système de fichier cible existe déjà, l'opération se termine avec succès.
        -s Créer un volume sparse sans réservation.
        -o property=value Définis la propriété spécifiée. Peut être spécifié plusieurs fois
        -b blocksize Équivaleunt à -o volblocksize=blocksize.

zfs destroy [-rRf] filesystem|volume Détruit le dataset donné. Par défaut, la commande départage tous systèmes de fichier partagé, démonte tous les systèmes de fichier actuellement monté, et refuse de détruire un dataset qui a une dépendance active (enfant ou clone).

        -r Détruit récursivement tout enfant
        -R Détruit récursivement toutes les dépendances, incluant les clones en dehors de la hiérarchie cible.
        -f Force à démonter les systèmes de ficiher en utilisant umount -f. N'a d'effet que sur les systèmes de fichier, et montés.

zfs destroy [-rRd] snapshot Détruit le snapshot donné si et seulement si la commande zfs destroy l'aurait détruit sans l'option -d. Si le snapshot n'est pas qualifié pour une destruction immédiate, il est marqué pour une suppression déferrée. Dans cet état, il est utilisable et visible jusqu'à ce que les conditions pour sa suppression soient rencontrées.

        -d Défère la suppression
        -r Détruit ou marque pour suppression tous les snapshots avec ce nom dans le système de fichier descendant.
        -R Détruit récursivement toutes les dépendances.

zfs snapshot [-r] [-o property=value] ... filesystem@snapname|volume@snapname Créer un snapshot avec le nom donné. Toutes les modifications précédente dans le système de fichier font partie du snaphot.

        -r Créer des snapshot récursivement pour tous les datasets descendants. Les snapshots sont pris automatiquement, donc tous les snapshots pris correspondent au même moment dans le temps.
        -o property=value Définis la propriété spécifiée.

zfs rollback [-rRf] snapshot Applique un précédent snapshot a un dataset. Par défaut, la commande refuse d'appliquer un snapshot autre que le plus récent. Les options -rR ne détruisent pas récursivement les snapshots enfant. Seul le snapshot récurisf top-level est détruit par une de ces options. pour appliquer un snapshot récursif complet, il faut l'appliquer individuellement aux snapshots enfant.

        -r Détruit récursivement tous snapshots plus récent que celui spécifié
        -R Détruit récursivement tous des snapshots plus récent, ainsi que les clones de ces snapshots.
        -f Utilisé avec -R force à démonter tous systèmes de fichier clone qui doivent être détruits

zfs clone [-p] [-o property=value] ... snapshot filesystem|volume Crée un clone d'un snapshot donné.

        -p créé tous les datasets parent non-existants. Les datasets crées de cette manière sont automatiquement montés en accord avec la propriété mountpoint héritée de leur parent.
        -o property=value Définis la propriété spécifiée.

zfs promote clone-filesystem Détache un clone de système de fichier de son snapshot original. Cela permet de détruire le système de fichier depuis lequel ce clone a été créé. La relation de dépendance de clone parent-enfant est réservée, donc le système de fichier d'origine devient un clone du système de fichier spécifié. Le snapshot qui a été cloné, et tous les snapshots précédents à ce snapshot, sont désormais possédés par le clone promus. L'espace qu'ils utilisent se déplace du système de fichier original avec le clone promus, il doit donc y avoir suffisamment d'espace pour ces snapshots. Aucun nouvel espace n'est consommé par cette opération, mais l'espace est ajusté. Le clone promu ne doit pas avoir de conflits de noms de snapshot.
zfs rename filesystem|volume|snapshot filesystem|volume|snapshot
zfs rename [-p] filesystem|volume filesystem|volume Renomme le dataset donné. La nouvelle cible peut être localisée n'importe où dans la hiérarchie ZFS, à l'exception des snapshots. Les snapshots peuvent seulement être renommés dans le système de fichier parent ou les volumes. En renommant un snapshot, le système de fichier parent du snapshot n'a pas besoin d'être spécifié comme partie du second argument. Les système de fichie renomés peuvent hériter de nouveaux points de montage, auquel cas ils sont démonté et remontés dans le nouveau point.

        -p Crée tous les datasets parent non-existant. Les datasets ainsi créés de cette manière sont automatiquement montés en accord avec la propriété mountpoint hérité du parent.

zfs rename -r snapshot snapshot Renome récursivement les snapshots de tous les datasets descendants. Les snapshots sont les seuls datasets qui peuvent être renommés récursivement.
zfs list [-r|-d depth] [-H] [-o property[,...]] [ -t type[,...]] [ -s property ] ... [ -S property ] ... [filesystem|volume|snapshot] ...Liste les informations de propriété pour les datasets donnés sous forme de tableau. Si spécifié, vous pouvez lister les informations de propriétés par chemin absolu ou relatif. Par défaut, tous les systèmes de fichier et volumes sont affichés.

        -H Utilisé pour le scripting. N'affiche pas les en-têtes, et sépare les champs par une simple tabulation.
        -r Affiche récursivement les enfants du dataset.
        -d depth Affiche récursivement les enfants du dataset, en limitant la profondeur de la récursion.
        -o property Liste de propriétés à afficher. Peut être une propriété native, utilisateur, name pour affichier le nom du dataset, et space pour afficher l'utilisation disque.
        -s property Une propriété pour le trie dans l'ordre ascendant basée sur la valeur de la propriété..
        -S property Idem mais dans l'ordre descendant.
        -t type Liste de type à affichier ( filesystem, snapshot, volume ou all).

zfs set property=value filesystem|volume|snapshot ... Définis la propriété à la valeur donnée pour chaque dataset.
zfs get [-r|-d depth] [-Hp] [-o all | field[,...] [-s source[,...]] all | property[,...] filesystem|volume|snapshot ... Affiche les propriété pour les datasets donné. si aucun dataset n'est donné, affiche les propriétés pour tous les datasets.

        -r Affiche les propriétés des enfants du dataset.
        -d depth Affiche récursivement les enfants du dataset, en limitant la profondeur de la récursion.
        -H Sort dans un format plus facile à parser par les scripts
        -o field Définis les champs à afficher, parmi: name,property,value,received,source,all
        -s source Liste de sources à afficher. chaque source doit être un parmi: local,default,inherited,temporary,received,none
        -p Affiche les nombres en valeurs parsable (exactes)

zfs inherit [-rS] property filesystem|volume|snapshot ... Efface les propriétés spécifiée, forcant l'héritage du parent.

        -r Hérite récursivement de la propriété donnée pour tous les enfants
        -S Revient à la valeur de propriété reçue si possible.

zfs upgrade [-v] affiche une liste de systèmes de fichiers qui ne sont pas à la dernière version
zfs upgrade [-r] [-V version] [-a | filesystem] Met à jours les systèmes de fichiers à une version plus récente. En générale, la version est dépendante de la version du pool.

        -a Met à jours tous les systèmes de fichier dans tous les pools importés
        filesystem Met à jours le système de fichier spécifié
        -r Met à jours le système de fichier spécifié et tous ses descendants.
        -V version Met à jours à la version spécifiée.

zfs userspace [-niHp] [-o field[,...]] [-sS field]... [-t type [,...]] filesystem | snapshot Affiche l'espace consommé, et les quotas, de chaque utilisateur dans le système de fichier spécifié ou le snapshot. Cela correspond aux propriétés userused@user et userquota@user

         -n Affiche l'ID numérique au lieu du nom
        -H Sort dans un format plus facile à parser par les scripts
        -p Affiche les nombres en valeurs parsable (exactes)
        -o field Définis les champs à afficher, parmi: type,name,used,quota. Défaut: affiche tous les champs
        -s field Trie la sortie par ce champs. Peut être spécifié plusieurs fois.
        -S field idem, mais trie dans l'ordre inverse
        -t type[,...] Affiche seulement les types spécifiés du jeu suivant: all,posixuser,smbuser,posixgroup,smbgroup. Défaut: posixuser,smbuser
        -i Traduit SID en POSIX ID.

zfs groupspace [-niHp] [-o field[,...]] [-sS field]... [-t type [,...]] filesystem | snapshot Affiche l'espace consommé, et les quotes, pour chaque groupe dans le système de fichier spécifié ou le snapshot. Cette sous commande est identique à zfs userspace, excepté que le type d'affichage pas défaut est -t posixgroup,smbgroup
zfs mount Affiche tous les systèmes de fichiers montés
zfs mount [-vO] [-o options] -a | filesystem Monte les systèmes de fichiers ZFS. Invoqué automatiquement durant le processus de démarrage

        -o options liste d'options de montage à utiliser temporairement
        -O montage overlay
        -v Reporte la progression du montage
        -a Monte tous les systèmes de fichiers zfs disponible.
        filesystem Monte le système de fichier spécifié

zfs unmount [-f] -a | filesystem|mountpoint Démonte les systèmes de fichiers zfs. Invoqué automatiquement durant le processus d'arrêt

        -f Force à démonter tous les systèmes
        -a Démonte tous les systèmes de fichiers zfs
        filesystem|mountpoint Démonte le système de fichier spécifié.

zfs share -a | filesystem Partage un système de fichier zfs

        -a Partage tous les systèmes de fichier zfs. Invoqué automatiquement durant le processus de démarrage
        filesystem Partage le systèmes de fichier en accord avec les propriétés sharenfs et sharesmb.

zfs unshare -a | filesystem|mountpoint Ne partage plus les systèmes de fichier zfs. Invoqué automatiquement durant le processus d'arrêt

        -a dé-partage tous les systèmes de fichier zfs
        filesystem|mountpoint dé-partage le système de fichier spécifié

zfs send [-DvRp] [-[iI] snapshot] snapshot Créé une représentation flux du second snapshot, qui est écris sur la sortie standard. La sortie peut être redirigée dans un fichier ou sur un système différent.

        -D Effectue un traitement dedup sur le flux.
        -i snapshot génère un flux incrémentale depuis le premier snapshot dans le second. La source incrémentale (le premier snapshot) peut être spécifié comme dernier composant du nom du snapshot (par exemple, la partie après le @ ), et il est assumé être du même système de fichier que le second snapshot. Si la destination est un clone, la source peut être le snapshot d'origine, qui doit être spécifié en entier (ex: pool/fs@origin).
        -I snapshot Génère un package flux qui envoie tous les snapshots intermédiaire depuis le premier snapshot jusqu'au second.
        -R Génère un package flux de réplication, qui va répliquer le système de fichier spécifié, et tous les systèmes de fichier descendants, jusqu'au snapshot nommé. Toutes les propriétés, snapshots, systèmes de fichiers descendants et clones sont préservés. Si -i et -I sont utilisé avec -R, un flux de réplication incrémentale est généré.
        -p Envoie les propriétés
        -v Affiche des informations sur le flux généré.

zfs receive [-vnFu] filesystem|volume|snapshot
zfs receive [-vnFu] [-d | -e] filesystem Crée un snapshot dont le contenu est spécifié dans le flux fournis sur l'entrée standard. Si un flux complet est reçu, le nouveau système de fichier est créé également.
Si un flux incrémentale est reçu, le système de destination doit déjà exister, et son snapshot le plus récent doit matcher la source du flux incrémentale. Pour les zvols, le lien du périphérique de destination est détruit et recréé, ce qui signifie que le zvol ne peut être accédé durant l'opération.
Quand un flux de réplication de snapshot généré par zfs send -R est reçu, tout snapshot qui n'existent pas dans l'emplacement d'origine est détruit via zfs destroy -d.
Le nom du snapshot (et du système de fichier, si un flux complet est reçu) que cette sous-commande créé dépends du type d'argument et des options -d ou -e.
Si l'argument est un nom de snapshot, il est créé. Si l'argument est un système de fichier ou un nom de volume, un snapshot avec le même nom que le snapshot envoyé est créé dans le système de fichier ou le volume spécifié. Si l'option -e ou -d est spécifiée, le nom du snapshot est déterminé en ajoutant le nom du snapshot au système de fichier spécifié. Si -d est spécifié, tous sauf le nom du pool du snapshot envoyé est ajouté. (ex: b/c@1 ajouté depuis a/b/c@1), et si -e est spécifié, seul la fin du chemin est ajouté (ex: c@1).

        -d Utilise tout sauf le premier élément du chemin du snapshot envoyé pour déterminer le nom du nouveau snapshot.
        Utilise le dernier élément du chemin du snapshot envoyé pour déterminer le nom du nouveau snapshot.
        -u Le système de fichier qui est associé avec le flux reçu n'est pas monté
        -v Affiche des informations sur le flux et le temps requis pour effectuer l'opération.
         -n Ne reçoit pas le flux. Utile avec -v pour vérifier le nom.
        -F Force le rollback du système de fichier au snapshot le plus récent avant d'effectuer l'opération.

zfs allow filesystem | volume Affiche les permissions qui ont été délégués dans le système de fichier spécifié ou le volume.
zfs allow [-ldug] "everyone"|user|group[,...] perm|@setname[,...] filesystem| volume
zfs allow [-ld] -e perm|@setname[,...] filesystem | volume Délègue les permissions d'administration ZFS pour les systèmes de fichier à des utilisateurs non-privilégiés.

        [-ug] "everyone"|user|group[,...] Spécifie à que des autorisation sont déléguées. Plusieurs entités peuvent être spécifiées. Si -u et -g n'est pas spécifié, l'argument est interprété préférentiellement pour tout le monde, puis comme nom d'utilisateur, et enfun comme nom de groupe. Pour spécifier un utilisateur ou un groupe nommé "everyone", utiliser -u ou -g. Pour spécifier un groupe avec le même nom que l'utilisateur, utiliser l'option -g.
        [-e] perm|@setname[,...] Spécifie les permissions à déléguer à "everyone". Plusieurs permissions peuvent être spécifiée. Les noms de permission sont les même que la même sous-commande ZFS ou nom de propriété. Voir la liste plus bas. Les noms de jeu de propriété, qui commencent par @, peuvent être spécifiés.
        [-ld] filesystem|volume Spécifie où les permissions sont déployées. Si -l et -d n'est pas pécifié, ou les 2 le sont, les permissions sont permises pour le système de fichier ou le volume, et tous ses descendants. Il seul -l est utilisé, c'est permis localement seulement pour le système de fichier spécifié. Si seul -d est utilisé, c'est permis seulement pour les systèmes de fichiers descendants.

Les permissions sont généralement la capacité d'utiliser une sous-commande ou changer une propriété zfs. Les permissions suivantes sont permises:
NAME_____________TYPE__________ NOTES
allow____________subcommand_____Doit également avoir la permission qui est permise
clone____________subcommand_____Doit également avec la capacité 'create' et 'mount' dans le système de fichier d'origine
create___________subcommand_____Doit également avoir la capacité 'mount'
destroy__________subcommand_____Doit également avoir la capacité 'mount'
hold_____________subcommand_____Permet d'ajouter un utilisateur maintenu dans un snapshot
mount____________subcommand_____Permet de monter/démonter des datasets
promote__________subcommand_____Doit également avoir les capacités 'mount' et 'promote' dans le système de fichie d'origine
receive__________subcommand_____Doit également avoir les capacités 'mount' et 'create'
release__________subcommand_____Permet d'enlever un user qui peut détuire le snapshot
rename___________subcommand_____Doit également avec la capacité 'create' et 'mount' dans le nouveau parent
rollback_________subcommand
send_____________subcommand
share____________subcommand_____Permet de partager des systèmes de fichier sur NFS ou SMB
snapshot_________subcommand
groupquota_______other__________Permet d'accéder à toutes les propriétés groupquota@...
groupused________other__________Permet de lire toutes les propriété groupused@...
userprop_________other__________Permet de changer toute propriété utilisateur
userquota________other__________Permet d'accéder à toutes les propriétés les userquota@...
userused_________other__________Permet de lire toutes les propriétés userused@...
aclinherit_______property
aclmode__________property
atime____________property
canmount_________property
casesensitivity__property
checksum_________property
compression______property
copies___________property
dedup____________property
devices__________property
exec_____________property
logbias__________property
mlslabel_________property
mountpoint_______property
nbmand___________property
normalization____property
primarycache_____property
quota____________property
readonly_________property
recordsize_______property
refquota_________property
refreservation___property
reservation______property
secondarycache___property
setuid___________property
shareiscsi_______property
sharenfs_________property
sharesmb_________property
snapdir__________property
utf8only_________property
version__________property
volblocksize_____property
volsize__________property
vscan____________property
xattr____________property
zoned____________property

zfs allow -c perm|@setname[,...] filesystem|volume Définis les permission "create time". Ces permission sont données localement au créateur d'un nouveau système de fichier descendant créé.
zfs allow -s @setname perm|@setname[,...] filesystem|volume Définis ou ajoute des permissions à un jeu de permission. Le jeu peut être utilisé par d'autres commande zfs allow pour le système de fichier spécifié et ses descendants. Les jeux sont évalués dynamiquement, donc changer un set est reflété dynamiquement. Les jeux de permission suivent les même restrictions de nommage que les systèmes de fichiers ZFS, mais le nom doit commencer par '@' et ne peut pas faire plus de 64 caractères.
zfs unallow [-rldug] "everyone"|user|group[,...] [perm|@setname[, ...]] filesystem|volume
zfs unallow [-rld] -e [perm|@setname [,...]] filesystem|volume
zfs unallow [-r] -c [perm|@setname[,...]] filesystem|volume Supprime les permissions qui ont été données avec la commande zfs allow. Aucune permissions n'est explicitement refusée, donc les permissions données restent effectives. Si aucune permission n'est spécifiée, toutes les permissions pour l'utilisateur, groupe, ou everyone sont supprimés. Spécifier everyone ou l'option -e supprime seulement les permissions qui ont été donnée à everyone.

        -r Supprime récursivement les permissions dans le système de fichier et ses descendants

zfs unallow [-r] -s @setname [perm|@setname[,...]] filesystem|volume Supprime les permissions d'un jeu de permissions. Si aucune permission n'est spécifiée, supprime toutes les permissions et supprime le jeu.
zfs hold [-r] tag snapshot... Ajoute une référence simple, nommée avec l'argument tag, au snapshot ou aux snapshots spécifiés Chaque snapshot a son propre espace de nom de tag, et les tags doivent être unique dans cet espace. Si un hold existe dans un snapshot, tenter de détruire ce snapshot en utilisant zfs destroy retourne EBUSY.

        -r Spécifie qu'un hold avec le tag donné est appliqué récursivement aux snapshots de tous les systèmes de fichiers descendants.

zfs holds [-r] snapshot... Liste toutes les références utilisateurs existant pour un snapshot donné

        -r Liste les holds qui sont définis dans les snapshots descendants nommés, en plus de lister les holds dans le snapshot nommé.

zfs release [-r] tag snapshot... Supprime une simple référence, nommée avec l'argument tax, du ou des snapshots spécifiés. Le tag doit déjà exister.

        -r Supprime récursivement un hold dans les snapshots et tous les système de fichier descendants.

Exemples

Créer une hiérarchie de système de fichier zfs:
zfs create pool/home
zfs set mountpoint=/export/home pool/home
zfs create pool/home/bob
Créer un snapshot ZFS. Ce snapshot est monté à la demande dans le .zfs/snapshot dans le système de fichier pool/home/bob:
zfs snapshot pool/home/bob@yesterday
Créer et détruire plusieurs snapshots:
zfs snapshot -r pool/home@yesterday
zfs destroy -r pool/home@yesterday
Désactive et active la compression de système de fichier
zfs set compression=off pool/home
zfs set compression=on pool/home/anne
Lister les datasets
zfs list
Définir un quota dans un système de fichier
zfs set quota=50G pool/home/bob
Lister les propriétés ZFS:
zfs get all pool/home/bob
Lister une simple propriété
zfs get -H -o value compression pool/home/bob
Liste toutes les propriété avec les paramètres locaux:
zfs get -r -s local -o name,property,value all pool/home/bob
Rollback un système de fichier
zfs rollback -r pool/home/anne@yesterday
Créer un clone:
zfs clone pool/home/bob@yesterday pool/clone
Détacher un clone:
zfs create pool/project/production
zfs snapshot pool/project/production@today
zfs clone pool/project/production@today pool/project/beta
zfs promote pool/project/beta
zfs rename pool/project/production pool/project/legacy
zfs rename pool/project/beta pool/project/production
zfs destroy pool/project/legacy
Hériter des propriétés ZFS:
zfs inherit checksum pool/home/bob pool/home/anne
Répliquer les données ZFS à distance:
zfs send pool/fs@a | ssh host zfs receive poolB/received/fs@a
poolB doit contenir le système de fichier poolB/received et ne doit pas contenir initialement pooB/received/fs
zfs send -i a pool/fs@b | ssh host zfs receive poolB/received/fs
Utiliser zfs receive -d
zfs send poolA/fsA/fsB@snap | ssh host zfs receive -d poolB/received
Définir les propriétés utilisateurs:
zfs set com.example:department=12345 tank/accounting
Créer un volume ZFS comme target iSCSI:
zfs create -V 2g pool/volumes/vol1
zfs set shareiscsi=on pool/volumes/vol1
iscsitadm list target
Maintenir un historique de snapshots dans un schéma de nommage consistant:
zfs destroy -r pool/users@7daysago
zfs rename -r pool/users@6daysago @7daysago
zfs rename -r pool/users@5daysago @6daysago
zfs rename -r pool/users@yesterday @5daysago
zfs rename -r pool/users@yesterday @4daysago
zfs rename -r pool/users@yesterday @3daysago
zfs rename -r pool/users@yesterday @2daysago
zfs rename -r pool/users@today @yesterday
zfs snapshot -r pool/users@today
Définis la propriété sharenfs dans un système de fichier zfs:
zfs set sharenfs='rw=@123.123.0.0/16,root=neo' tank/home
Déléguer les permissions d'administration dans un dataset:
zfs allow cindys create,destroy,mount,snapshot tank/cindys
zfs allow tank/cindys
Parce que les permissions du point de montage tank/cindys est à 755 par défaut, cindys ne sera pas capable de monter les systèmes de fichier sous tank/cindys. Définir une ACL similaire à la syntaxe suivante:
chmod A+user:cindys:add_subdirectory:allow /tank/cindys
Déléguer la permission create time dans un dataset:
zfs allow staff create,mount tank/users
zfs allow -c destroy tank/users
zfs allow tank/users
Définir et donner un jeu de permission dans un dataset:
zfs allow -s @pset create,destroy,snapshot,mount tank/users
zfs allow staff @pset tank/users
zfs allow tank/users
Déléguer les permissions de propriété dans un dataset:
zfs allow cindys quota,reservation users/home
zfs allow users/home
Supprimer les permissions déléguer dans un dataset:
zfs unallow staff snapshot tank/users
zfs allow tank/users
^
16 janvier 2015

htmlpdflatexmanmd




zfs-fuse

zfs-fuse

Service de système de fichier ZFS

OPTIONS

-p filename --pidfile filename Écris le PID du service dans filename. Ignoré si --no-daemon est passé.
-n, --no-daemon Ne passe pas en tâche de fond.
--no-kstat-mount Ne monte pas kstats dans /zfs-kstat
--disable-block-cache Active les opération disque direct E/S. Désactive complètement les caches de lecture et d'écriture dans le cache de block du kernel.
--disable-page-cache Désactive le cache de page pour les fichiers résidant dans les systèmes de fichiers ZFS. Non recommandés, ralentis les opération.
-a SECONDS --fuse-attr-timeout SECONDS Définis le timeout pour le cache des attributs FUSE dans le kernel ( défaut: 0.0 ). Des valeurs supérieurs boost les performances de 40%
 -e SECONDS --fuse-entry-timeout SECONDS Définis le timeout pour le cache d'attributs FUSE dans le kernel ( défaut: 0.0 ). Des valeurs supérieurs boost les performances de 10000%, mais crées de problèmes de sécurité dans la vérification des permissions de fichier.
--log-uberblocks Logs uberblocks de tous les systèmes de fichiers montés dans syslog
-m MB --max-arc-size MB Force la taille maximum ARC ( en mégaoctets). (de 16 à 16384)
-o OPT... --fuse-mount-options OPT,OPT,OPT... Définis les options de montage FUSE pour tous les systèmes de fichiers.
-u MIN --min-uberblock-txg MIN Saute les uberblocks avec un TXG ‹ MIN en montant les fs
-v MB --vdev-cache-size MB Ajuste la taille du cache vdev. défaut 10.
--zfs-prefetch-disable Désactive le cache prefetch de haut niveau dans zfs. peut consommer jusqu'à 150Mo de ram, voir plus.
--stack-size=size Limite la taille de pile des threads en Kb. Défaut: pas de limite (8Mo pour Linux)
-x --enable-xattr Active le support pour les attributs étendus. Généralement non recommandé parce que cela impacte significativement les performances.

Notes

   Les paramètres passés sur la ligne de commande ont précédence sur ceux fournis dans /etc/zfs/zfsrc.
^
16 janvier 2015

htmlpdflatexmanmd




zfsrc

zfsrc

Fichier de configuration pour zfs-fuse

vdev-cache-size Ajuste la taille du cache vdev. défaut 10.
max-arc-size Force la taille maximum ARC ( en mégaoctets). (de 16 à 16384)
zfs-prefetch-disable Désactive le cache prefetch de haut niveau dans zfs. peut consommer jusqu'à 150Mo de ram, voir plus.
disable-block-cache Active les opération disque direct E/S. Désactive complètement les caches de lecture et d'écriture dans le cache de block du kernel.
disable-page-cache Désactive le cache de page pour les fichiers résidant dans les systèmes de fichiers ZFS. Non recommandés, ralentis les opération.
enable-xattr Active le support pour les attributs étendus. Généralement non recommandé parce que cela impacte significativement les performances.
fuse-attr-timeout Définis le timeout pour le cache des attributs FUSE dans le kernel ( défaut: 0.0 ). Des valeurs supérieurs boost les performances de 40%
fuse-entry-timeout Définis le timeout pour le cache d'attributs FUSE dans le kernel ( défaut: 0.0 ). Des valeurs supérieurs boost les performances de 10000%, mais crées de problèmes de sécurité dans la vérification des permissions de fichier.
fuse-mount-options Définis les options de montage FUSE pour tous les systèmes de fichiers.
stack-size Limite la taille de pile des threads en Kb. Défaut: pas de limite (8Mo pour Linux)

^
16 janvier 2015

htmlpdflatexmanmd




zpool

zpool

Configure des pools de stockage ZFS

Description

   Un pool de stockage est une collection de périphériques qui fournissent un stockage physique et une réplication de données pour les datasets ZFS. Tous les datasets dans un pool de stockage partagent le même espace.

   Un périphérique virtuel (vdev) décrit un simple périphérique ou une collection de périphériques organisés en accord avec certaines caractéristiques de performances et panne. Les périphériques virtuels suivants sont supportés:

disk Un périphérique block, typiquement localisé sous /dev/dsk. ZFS peut utiliser individuellement des slices ou des partitions, mais le mode d'opération recommandé est d'utiliser des disques entiers. Un dique peut être spécifié par un chemin complet, ou il peut être un nom cour ( la partie relative à /dev/dsk). Un disque entier peut être spécifié en omettant le slice ou la partition. par exemple, "c0t0d0" est équivalent à "/dev/dsk/c0t0d0s2". En donnant un disque entier, ZFS lablel automatiquement le disque, si nécessaire.
file Un fichier régulier. L'utilisation de disques régulier est fortement découragé. Il est conçu principalement à des fins expérimentaux.
mirror Un mirroir de 2 ou plusieurs disques. Les données sont répliquées de manière identique dans tous les composant d'un mirroir. Un mirroir avec N disques et taille X peut maintenir X octets et peut résister à N-1 panne de périphériques avant que l'intégrité des données soient compromise.
raidz
raidz1
raidz2
raidz3 Une variation du RAID-5 qui permet une meilleur distribution de la parité et élimine les trous d'écriture des RAID-5 (dans lequel les données et la parité deviennent inconsistants avec une coupure de courant). Les données et la parité sont placés dans tous les disques dans un groupe raidz.
Un groupe raidz peut avoir une parité simple, double ou triple, signifiant que le groupe raidz peut survivre à 1, 2, ou 3 erreurs, respectivement, sans perte de données. raidz est un alias de raidz1.
Un group raidz avec N disques de taille X avec P disques de parité peut maintenir approximativement (N-P)*X octets et peut résister à P pannes de périphériques avec que l'intégrité des données soit compromise. Le nombre minimum de périphériques dans un group raidz est un de plus que le nombre de disque de parité. Le nombre recommandé est entre 3 et 9 pour améliorer les performances.
spare Un pseudo vdev spécial qui conserve la trace de disques de rechange à chaud pour un pool.
log Un périphérique de log séparé. Si plus d'un périphérique de log sont spécifiés, les écritures sont load-balancés entre les disques. Les périphériques de log peuvent être en mirroir. Cependant, les vdev raidz ne sont pas supportés.
cache Un périphérique utilisé comme cache de données. Un périphérique cache ne peut pas être configuré comme mirroir ou groupe raidz.

   Les périphériques virtuels ne peuvent pas être imbriqués, donc un périphérique mirroir ou raidz ne peut contenir que les fichiers et des disques. Les mirroirs de mirroirs ou d'autres combinaisons ne sont pas permises.

   Un pool peut avoir n'importe quel nombre de périphériques virtuels en haut de la configuration ( "root vdevs" ). Les données sont dynamiquement distribués dans tous les périphériques de haut niveau pour load-balancer dans les périphériques. Comme avec les nouveaux périphériques virtuels, ZFS place automatiquement les données dans les nouveaux périphériques disponibles.

   Les périphériques virtuels sont spécifié une à la fois dans la ligne de commande, séparés par des espaces blancs. Les mots clé "mirror" et "raidz" sont utilisé pour distinguer où un groupe se termine et où un autre commence.

Par exemple, pour créer 2 vdev root, chaque en mirroir de 2 disques:
zpool create mypool mirror c0t0d0 c0t1d0 mirror c1t0d0 c1t1d0

Erreur disque et récupération

   ZFS supporte plusieurs mécanismes pour gérer les erreurs disques et la corruption de données. Toutes les métadonnées et les données sont hashé, et ZFS répare automatiquement les mauvaises données depuis une bonne copie quand une corruption est détectée.

   Pour pouvoir utiliser ces fonctionnalités, un pool doit utiliser une certaine forme de redondance, en utilisant soit des groupes mirroir ou raidz. Bien que ZFS supporte les configuration non-redondantes, où chaque vdev root est simplement un disque ou un fichier, c'est fortement découragé.

   Le status de santé d'un pool est décris par un de ces 3 états: online, degraded, faulted. Un pool online a tous ses périphériques fonctionnant normalement. Un pool dégradé est un pool dans lequel un ou plusieurs périphériques sont en échec, mais les données continuent d'être disponibles grâce à la configuration de la redondance. Un pool faulted est un pool qui a une corruption de méta-données, un ou plusieurs périphériques en erreur, et des réplicas insuffisant pour continuer à fonctionner.

   La santé du vdev top-level, tel un mirror ou un raidz, est potentiellement impacté par l'état de ses vdev associés, ou ses périphériques. Un vdev top-level ou un composant périphérique est dans un de ces états:

DEGRADED

- Un ou plusieurs vdev top-level sont en état dégradés à cause d'un ou plusieurs composants périphérique offline. Des réplicas suffisants existent pour continuer à fonctionner.
- Un ou plusieurs composants périphérique et est en état dégradé ou faulted, mais des réplicas suffisants existent pour continuer à fonctionner. Les conditions sous-jacentes sont les suivantes:

        - Le nombre d'erreurs de checksums excède le niveau acceptable et le périphérique est dégradé en indication que quelque chose ne va pas. ZFS continue d'utiliser le périphérique si nécessaire.
        - Le nombre d'erreur E/S excède le niveau acceptable. Le périphérique ne pourrait pas être marqué en faulted parce qu'il y'a suffisamment de réplicas pour continuer à fonctionner.

FAULTED

- Un ou plusieurs vdev top-level sont à l'état faulted à cause d'un ou plusieurs composants périphérique offline. Les réplicas existant sont insuffisant pour continuer à fonctionner.
- Un ou plusieurs composant périphérique sont à l'état faulted, et des réplicas existant sont insuffisant pour continuer à fonctionner. Les conditions sous-jacentes sont les suivantes:

        - Le périphérique peut être ouvert, mais son contenu ne matche par les valeurs attendues
        - Le nombre d'erreur d'E/S excède un niveau acceptable et le périphérique est faulted pour empêcher son utilisation.

OFFLINE

- Le périphérique a été explicitement mis offline par la commande zpool offline

ONLINE

- Le périphérique est online et fonctionnel

REMOVED

- Le périphérique a été physiquement supprimé alors que le système fonctionnait. La détection de la suppression de disque est dépendant du hardware et peut ne pas être supporté par toutes les plateformes.

UNAVAIL

- Le périphérique ne peut pas être ouvert. Si un pool est importé quand un périphérique est indisponible, le périphérique sera identifié par un identifiant unique au lieu de son chemin vu que le chemin n'est jamais correct.

   Si un périphérique est supprimé puis ré-attaché plus tard dans le système, ZFS tente de placer le périphérique automatiquement en online. La détection de périphérique attaché est dépendant du hardware et peut ne pas être supporté par toutes les plateformes.

Hot Spares

   ZFS permet aux périphériques d'être associés avec des pools en hot spare avec la commande zpool add et supprimés avec la commande zpool remove. Une fois un spare initialisé, un nouveau vdev spae est créé dans la configuration qui va rester jusqu'à ce que le périphérique original soit remplacé. À ce point, le hot spare deviendra disponible si un autre périphérique échoue.

   Si un pool a un spare partagé qui est actuellement utilisé, le pool ne peut pas être exporté vu que d'autre pools peuvent utiliser ce spare partagé.

   Tout spare en progression de remplacement peut être annulé en détachant le hot spare. Si le périphérique faulted est détaché, le hot spare assume sa place dans la configuration, et est supprimé de la liste de spare pour tous les pools actifs.

   Les spares ne peuvent pas replacer les périphériques logs

Intent Log

   ZFS Intent Log (ZIL) satisfait les pré-requis POSIX pour les transactions synchrones. Actuellement, les bases de données nécessitent que leur transactions soient sur des périphériques de stockage stables en retournant depuis un appel système. NFS et d'autres applications peuvent également utilis fsync() pour s'assurer de la stabilité des données. Par défaut, le intent log est alloué dans les blocks du pool principal. Cependant, il peut être possible d'obtenir de meilleurs performances en utilisant des périphériques séparés pou les logs tel que NVRAM ou un disque dédié.

Par exemple:
zpool create pool c0d0 c1d0 log c2d0

   Plusieurs périphériques de log peuvent également être spécifiés, et ils peuvent être mirrorés. Les périphériques de log peuvent être ajoutés, remplacés, attachés, détachés, et importés/exportés comme partie d'un grand pool. Les logs mirrorés peuvent être supprimés en spécifiant le mirror top-level pour les logs.

Cache Devices

   Des périphériques peuvent être ajoutés à un pool de stockage comme périphérique de cache. Ces périphériques fournissent une couche additionnelle de cache entre la mémoire principale et le disque. Pour des opérations de lecture intensive, utiliser des périphériques cache fournis les meilleurs performances.

Pour créer un pool avec des périphériques cache, spécifier un vdev cache avec des périphériques. par exemple:
zpool create pool c0d0 c1d0 cache c2d0 c3d0

   Les périphériques cache ne peuvent pas être mirrorés dans une configuration raidz. Si une erreur de lecture est rencontrée dans un périphérique cache, cette lecture est refaite dans le pool originale, qui peut faire partie d'une configuration mirror ou raidz. Le contenu des périphériques cache est considéré volatile.

Processus

   Chaque pool importé a un processus associé, nommé zpool-‹poolname›, les threads dans ce processus sont les threads de traitement E/S du pool, qui manipulent la compression, checsums, et d'autre tâches pour toutes les opération d'E/S associées avec le pool. Ce processus existe pour fournir un visibilité dans l'utilisation CPU. L'existence de ce processus est une interface instable.

Propriétés

   Chaque pool a de nombreuses propriétés. Certaines propriétés sont des statistiques lecture-seule alors que d'autre sont configurables. Les propriétés lecture-seules sont:

alloc Quantité d'espace de stockage dans le pool qui a été physiquement alloué.
capacity % de l'espace du pool utilisé.
deduplication Ration de déduplication spécifié pour un pool, exprimé comme multiplicateur. ex: 1.76 indique que 1.76 unité de donnée sont stockés mais seulement 1 unité de l'espace disque est consommé.
free Nombre de blocks dans le pool qui ne sont pas alloués.
guid Identifiant unique pour le pool
healt Santé actuel du pool.
size Taille totale du pool de stockage

   Ces propriétés d'utilisation de l'espace reportent l'espace physique actuellement disponible dans le pool. l'espace physique peut être différent de la taille totale d'espace que tout datasets peut utiliser actuellement. La quantité d'espace utilisé dans une configuration raidz dépend de ses caractéristiques. En plus, ZFS réserve de l'espace en interne que la commande zfs prend en compte, mais pas la commande zpool. Pour les pools non-pleins d'une taille raisonnable, ces effets devraient être invisibles. pour les petits pools, ou les pools qui sont presques pleins, ces écart peuvent devenir plus perceptibles.

   Les propriétés suivantes peuvent être définis à la création:

ashift Exposant de taille de secteur du pool, en puissance de 2. Les opérations I/O seront alignés à cette taille. Additionnellement La taille d'écriture disque minimum sera définis à la taille spécifiée, ce qui représente un compromis espace/performance. Le cas typique pour définir cette propriété est quand les performances sont importante et que les disques utilisent des secteurs 4KiB mais reportent des secteurs de 512 octets à l'OS pour des raisons de compatibilité; dans ce cas, définis ashift=12 ( 1‹㙘 == 4096 ). Vu que les grands disques ont des secteurs 4K depuis 2011, ZFS utilise ashift=12 par défaut pour tous les disques supérieurs à 512Go. Pour des raisons de performances, la taille de secteur devrait être égal ou supérieur à la taille de secteur.

   Les propriétés suivantes peuvent être définis à la création et à l'import:

altroot Répertoire root alternatif. Si définis, ce répertoire est ajouté à tout point de montage dans le pool. Cela peut être utilisé en examinant un pool inconnu où les points de montage ne peuvent pas être validés, ou dans un environnement de boot alternatif, où les chemins typiques ne sont pas valides. altroot n'est pas une propriété persistante. Elle est valide seulement quand le système est up.

   Les propriétés suivantes peuvent être définis à la création, à l'import et avec la command zpool set:

autoexpand=on | off Contrôle l'expansion automatique du pool quand le LUN sous-jacent grandis. À on, le pool sera redimmensionné en accord avec la taille du périphérique étendu. Si le périphérique fait partie d'un mirror ou un raidz, tous les périphériques dans le groupe doivent être étendus avant que le nouvel espace soit disponible dans le pool. (défaut: off).
autoreplace=on | off Contrôle le remplacement automatique du périphérique. À off, le remplacement de disque doit être initialisé par l'administrateur en utilisant zpool replace. à on, tout nouveau périphérique trouvé dans le même emplacement physique que l'ancien disque appartenant au pool est remplacé et formaté automatiquement. (défaut: off)
bootfs=pool/dataset Identifie le dataset bootable par défaut pour le pool root. Cette propriété est prévue pour être définie principalement par les programmes d'installation et de mise à jours.
cachefile=path | none Contrôle l'emplacement où la configuration du pool est cachée. Découvrir tous les pools au démarrage du système nécessite une copie cachée des données de configuration stockée dans le système de fichier racine. Tous les pools dans ce cache sont automatiquement importés au boot du système. Certains environnements, tels que l'installation et le clustering, nécessitent de cacher cette information dans un emplacement différent et ces pools ne sont pas automatiquement importés. Définir cette propriété met en cache la configuration du pool dans un emplacement différent et peut être importé ultérieurement avec zpool import -c. Définir la valeur spécial none créé un pool temporaire qui n'est jamais cacé, et la valeur spéciale "" utilise l'emplacement par défaut. Pluiseurs pools peuvent partager le même fichier de cache, mais le kernel détruis et recrée ce fichier quand les pools sont ajoutés ou recréés. quand le dernier poor utilisant cachefile est exporté ou supprimé, ce fichier est supprimé.
delegation=on | off Contrôle si un utilisateur non-privilégié à accès basé sur les permissions de dataset définis dans le dataset.
failmode=wait | continue | panic Contrôle le comportement du système dans l'éventualité d'une erreur catastrophique du pool. Cette condition est typiquement un résultat d'un perte de connectivité aux disques sous-jacents, ou une erreur de tous les disques dans le pool. Le comportement est déterminé comme suit:

        wait Bloque les accès E/S au pool jusqu'à ce que la connectivité au disque soit récupéré et que les erreurs aient été validés. Un pool reste en wait jusqu'à ce que le problème du périphérique soit résolu. C'est le mode par défaut.
        continue Retourne EIO à toute nouvelle demande d'écriture mais permet de lire tous périphérique en cour de fonctionnement.
        panic Affiche un message à la console et génère un crash dump système.

listsnaps=on | off Contrôle si les informations sur les snapshots associés avec ce pool sont affichés quand zfs list est lancé sans l'option -t. ( défaut: off ).
version=version Version courante du pool. Peut être augmenté, mais pas diminué. La méthode préférée pour mettre à jours les pools est avec la commande zpool upgrade. Cette propriété peut être tout nombre entre 1 et la version courante reportée par zpool ugrade -v.

Sous-commandes

   Toutes les sous-commandes qui modifient l'état sont loggés de manière persistante dans le pool dans leur forme original.

zpool add [-fn] [-o property=value] pool vdev ... Ajoute les périphériques virtuel spécifiés dans le pool donné.

        -f Force l'utilisation de vdev, même s'il apparaît en utilisation ou spécifie un conflit au niveau de la réplication.
         -n Affiche la configuration qui serai utilisée sans ajouter le vdev.
        -o property=value Définis les propriétés du pool donné (ashift). N'ajoute pas de disque qui est actuellement configuré comme périphérique quorum à un zpool. Une fois un disque dans le pool, ce disque peut être configuré comme périphérique quorum

zpool attach [-f] [-o property=value] pool device new_device Attache un nouveau périphérique à un zpool existant. Le périphérique existant ne peut pas faire partie d'une configuration raidz. Si device ne fait pas partie actuellement d'une configuration mirror, device se transforme automatiquement en mirror 2-way de device et new_device. Si device fait partie d'un mirror 2-way, attache new_device et créé un mirror 3-way, et ainsi de suite.

        -f Force l'utilisation de new_device, même s'il apparaît en cours d'utilisation.
        -o property=value Définie les propriété du pool donné (ashift).

zpool clear [-F [-n]] pool [device] ... Efface les erreurs disques dans un pool. Si aucun argument n'est spécifié, toutes les erreurs périphériques seront effacés. Si un ou plusieurs périphériques sont spécifiés, n'efface les erreurs que de ces périphériques.

        -F Initie le mode récupération pour un pool inouvrable. Tente d'annuler les dernières transactions dans le pool pour le retourner à un état normal. Tous les pools endommagé ne peuvent pas être récupérés avec cette option.
         -n Utilisé en combinaison avec -F. Vérifie si les transactions annulées renderaient le pool ouvrable, mais n'annule rien.

zpool create [-fn] [-o property=value] ... [-O file-system-property=value] ... [-m mountpoint] [-R root] pool vdev ... Créé un pool contenant les périphériques virtuels spécifié dans la ligne de commande. Le nom du pool doit commencer avec une lettre, et peut contenir des caractères alphanumériques, "_", "-" et ".". Les noms de pool mirror, raidz, spare et log sont réservés, comme les noms commençant par c[0-9]. La commande vérifie que chaque périphérique est accessible et non utilisés.
La commande vérifie également que la stratégie de réplication pour le pool est consistante. Une tentative de combiner des stockage redondant et non-redondants dans un seul pool, ou de mixer des disques et des fichier, cause une erreur sauf si -f est spécifié. L'utilisation de disques de taille différentes dans un simple raidz ou mirror est aussi marqué en erreur sauf si -f est spécifié.
Le point de montage par défaut est /‹pool›. Le point de montage ne doit pas exister ou doit être vide.

        -f Force l'utilisation des vdev, même s'ils apparaissent utilisé ou en conflit de niveau de réplication.
         -n Affiche la configuration qui serait utilisée sans créer le pool.
        -o property=value [-o property=value] ... Définis une propriété du pool
        -O file-system-property=value
        [-O file-system-property=value] ... Définis des propriétés de système de fichier dans le système de fichier root du pool.
        -R root Équivalent à "-o cachefile=none,altroot=root"
        -m mountpoint Définis le point de montage pour de dataset root. Le point de montage doit être un chemin absolu, legacy, ou none.

zpool destroy [-f] pool Détruit le pool donné, libérant les périphériques pour d'autres utilisations. Cette commande tente de démonter tout dataset actif avant de détruire le pool.

        -f Force un dataset actif contenu dans le pool à être démonté.

zpool detach pool device Détache device d'un mirroir. Cette opération est refusé s'il n'y a pas d'autre replica valide.
zpool export [-f] pool ... Exporte les pools donnés du système. Tous les périphériques sont marqués comme exporté, mais sont considérés en utilisation par d'autre sous-systèmes. Les périphériques peuvent être déplacés entre les systèmes et importés tant que le nombre de périphériques suffisant sont disponible.
Avant d'exporter le pool, tous les datasets dans le pool sont démontés. Un pool ne peut pas être exporté s'il a un spare partagé qui est actuellement utilisé. Pour que les pools soient portables, vous devez donner à zpool des disques entiers, pas seulement les slices, pour que zfs puisse labeliser les disques avec des labels EFI portables.

        -f Force à démonter les datasets.

zpool get "all" | property[,...] pool ... Récupère la liste donnée de propriété pour les pools spécifiés. Ces propriétés sont affichés avec les champs suivant:

        name Nom du pool
        property nom de la propriété
        value valeur de la propriété
        source Source de la propriété.

zpool history [-il] [pool] ... Affiche l'historique des commandes des pools spécifiés.

        -i Affiche les évènement ZFS loggé en interne en plus des évènements initiés par l'utilisateur.
        -l Affiche les logs au format long

zpool import [-d dir | -c cachefile] [-D] Liste les pool disponible à l'import. Si l'option -d n'est pas spécifié, cette commande recherche les périphériques dans /dev/dsk. Si le périphérique apparaît comme faisant partie d'un pool exporté, cette commande affiche des informations sur le pool. Les pools détruits, les pools qui ont été précédemment détruis avec zpool destroy, ne sont pas listés sauf si -D est spécifié.

        -c cachefile Lit la configuration depuis le cachefile donné qui a été créé avec la propriété cachefile.
        -d dir Recherche les périphériques ou fichiers dans dir. Peut être spécifié plusieurs fois.
        -D Liste les pools détruis uniquement.

zpool import [-o mntopts] [ -o property=value] ... [-d dir | -c cachefile] [-D] [-f] [-R root] [-F [-n]] -a Importe tous les pools trouvés dans les répertoirs de recherche. Identiquement à la commande précédante, excepté que tous les pools avec un nombre suffisant de périphériques sont importés. Les pools détruis, les pools qui ont été précédemment détruis par zpool destroy, ne sont pas importés sauf si -D est spécifié.

        -o mntopts Liste séparée par des ',' d'options de montages à utiliser en montant les datasets dans le pool.
        -o property=value Définis les propriétés spécifiées dans le pool importé.
        -c cachefile Lit la configuration depuis le cachefile donné qui a été créé avec la propriété cachefile.
        -d dir Recherche les périphériques ou les fichiers dans dir. Peut être spécifié plusieurs fois. Incompatible avec -c
        -D Importe les pools détruis uniquement. -f est requis
        -f Force l'import, même si le pool apparaît potentiellement actif.
        -F Mode récupération pour un pool non-importable. Tente de retourner le pool à un état importable en annulant les dernière transactions
        -a Recherche et importe tous les pools trouvés
        -R root Définis la propriété cachefile à none, et altroot à root.
         -n Utilisé avec -F. Détermine si un pool non-importable peut être importable, mais ne tente pas la récupération.

zpool import [-o mntopts] [ -o property=value] ... [-d dir | -c cachefile] [-D] [-f] [-R root] [-F [-n]] pool | id [newpool] Import un pool spécifique. Un pool peut être identifié par son nom ou l'identifiant numérique. Si newpool est spécifié, le pool est importé en utilisant le nom newpool. Sinon, il est importé avec le même nom que son nom exporté.
Si un périphérique est supprimé de son système sans utiliser zpool export avant, le périphérique apparaît comme potentiellement actif. Il ne peut pas être déterminé si c'était un export échoué, ou si le périphérique est vraiment en utilisation dans un autre hôte. Pour importer un pool dans cet état, l'option -f est requise.

        -o mntopts Liste séparée par des ',' d'options de montages à utiliser en montant les datasets dans le pool
        -o property=value Définis les propriétés spécifiées dans le pool importé.
        -c cachefile Lit la configuration depuis le cachefile donné qui a été créé avec la propriété cachefile.
        -d dir Recherche les périphériques ou les fichiers dans dir. Peut être spécifié plusieurs fois. Incompatible avec -c
        -D Importe les pools détruis uniquement. -f est requis
        -f Force l'import, même si le pool apparaît potentiellement actif.
        -F Mode récupération pour un pool non-importable. Tente de retourner le pool à un état importable en annulant les dernière transactions
        -a Recherche et importe tous les pools trouvés
        -R root Définis la propriété cachefile à none, et altroot à root.
         -n Utilisé avec -F. Détermine si un pool non-importable peut être importable, mais ne tente pas la récupération.

zpool iostat [-T u | d] [-v] [pool] ... [interval[count]] Affiche des statistiques d'E/S pour les pool donnés. En donnant un interval, rafraîchis toutes les interval secondes. Si aucun pool n'est spécifié, affiche pour tous les pools dans le système. Si count est spécifié, la commande se termine après count reports.

        -T u | d Affiche un horodatage.
        -v Statistiques plus complètes.

zpool list [-H] [-o props[,...]] [pool] ... Liste les pools donnés avec un status de santé et d'utilisation de l'espace. Sans argument, tous les pool dans le système sont listés.

        -H Mode scripté. N'affiche pas les headers, et sépare les champs pas une tabulation.
        -o props Liste séparée par des ',' de propriétés à afficher. (name, size, allocated, free, capacity, health, altroot).

zpool offline [-t] pool device ... Place les disques spécifié offline. Cette commande n'est pas applicable pour les caches et spares.

        -t Temporaire. Au reboot, le disque sera replacé à son état précédent.

zpool online [-e] pool device... Place un disque online. Cette commande n'est pas applicable pour les caches et spares.

         -e  Étend le périphérique pour utiliser tous l'espace disque disponible. Si le disque fait partie d'un mirror ou d'un raidz, tous les périphériques doivent être étendus avec que l'espace soit disponible dans le pool.

zpool remove pool device ... Supprime un périphérique du pool. Cette commande supporte seulement la suppression des hot spare, cache, et log.
zpool replace [-f] pool old_device [new_device] Remplace old_device avec new_device. C'est équivalent à attacher new_device, et détacher old_device. La taille de new_device doit être supérieur ou égal à la taille minimum de tous les périphériques dans un mirror ou raidz.
new_device est requis si le pool n'est pas redondant. Si new_device n'est pas spécifié, son défaut est old_device. Cette forme de remplacement est utile après qu'un disque existant ait crashé et a été physiquement remplacé. Dans ce cas, le nouveau disque peut avoir le même /dev/dsk que l'ancien périphérique, même s'il a une taille différente.

        -f Force l'utilisation de new_device, même s'il apparaît en utilisation.

zpool scrub [-s] pool ... Commence un scrub. Le scrub examine toutes les données dans les pools spécifiés pour vérifier qu'ils checksums correctement. Pour les périphériques répliqués, ZFS répare automatiquement tout dommage découvert durant le scrub. zpool status reporte la progression du scrub et affiche des informations sur son avancement.
Le scrubbing et le resilvering sont des opérations très similaires. La différence est que le resilvering examine seulement les données que ZFS sait être hors date (par exemple, en attachant un nouveau disque à un mirroir ou en replaçant un périphérique existantè), alors que le scrubbing examine toutes les données pour découvrir des erreurs dûs à des erreurs matériels ou disque.
Vu que le scrubbing et le resilvering sont des opération d'E/S intensifs, ZFS permet seulement un à la fois. Si un scrub est déjà en progression, zpool scrub se termine et recommence un nouveau scrub. Si un resilver est un progression, ZFS ne permet pas de démarrer un scrub.

        -s Stop le scrubbing

zpool set property=value pool Définis une propriété au pool spécifié.
zpool split [-R altroot] [-n] [-o mntopts] [-o property=value] pool newpool [device ...] Coupe un disque de chaque vdev top-level mirroré en un pool et crée un nouveau pool avec les disques splittés. Le pool original doit être fait d'un ou plusieurs mirroirs et ne doit pas être dans un processus de resilvering. Cette commande choisi le dernier périphérique dans chaque vdev mirror sauf spécification dans la ligne de commande.
En utilisant un argument device, split inclus les périphériques spécifiés dans un nouveau pool, si des périphériques restent non précisés, assigne le dernier périphérique de chaque mirroir vdev à ce pool, comme il le fait normallement. Si vour n'êtes pas certain de la sortie de spécit, utiliser -n pour s'assure que votre command aura l'effet attendus.

        -R altroot Import automatiquement le pool nouvellement créé avec le split, en utilisant le paramètre altroot spécifié.
         -n Affiche ce qu'il va faire, mais ne fait rien
        -o property=value Définis les propriétés spécifiées dans le pool importé.

zpool status [-xv] [pool] ... Affiche des status détaillés sur l'état de santé des pools donnés. Si aucun pool n'est spécifié, alors le status de chaque pool dans le système est affiché. Si un scrub ou un resilver est en cours, cette commande reporte le pourcentage fait et le temps estimé.

        -x Affiche seulement le status des pools qui ont des erreurs ou sont indisponible.
        -v Affiche plus d'information sur les erreurs.

zpool upgrade Affichue tous les pools formattés en utilisant une version ZFS différente. Les anciennes version peuvent continuer à être utilisée mais certaines fonctionnalité ne seront pas disponible. Ce pools peuvent être upgradé en utilisant zpool upgrade -a. Les pools qui sont formatés avec une version plus récente sont également affichés, bien que ces pool sont inaccessible au système.
zpool upgrade -v Affiche les versions ZFS supportés par le logiciel courant. Les versions ZFS courantes et tous les versions précédentes supportées sont affichées.
zpool upgrade [-V version] -a | pool ... Upgrade à a dernière version. Une fois fait le pool ne sera plus accessible aux système fonctionnant avec des versions plus anciennes.

        -a Upgrade tous les pools
        -V version Upgrade à la version spéifiée.

Exemples

Créer un Pool RAID-Z de 6 disques:
zpool create tank raidz c0t0d0 c0t1d0 c0t2d0 c0t3d0 c0t4d0 c0t5d0
Créer un pool avec 2 mirroirs de 2 disques chacuns.
zpool create tank mirror c0t0d0 c0t1d0 mirror c0t2d0 c0t3d0
Créer un pool en utilisant des slices:
zpool create tank /dev/dsk/c0t0d0s1 c0t1d0s4
Créer un pool en utilisant des fichiers:
zpool create tank /path/to/file/a /path/to/file/b
ajouter un mirroir à un pool:
zpool add tank mirror c1t0d0 c1t1d0
Lister les pools disponibles:
zpool list
Affiche toutes les propriété d'un pool:
zpool get all pool
Détruit un pool
zpool destroy -f tank
Exporte un pool:
zpool export tank
Importe un pool:
zpool import
zpool import tank
Upgrader les pools à la dernière version:
zpool upgrade -a
Gérer un spare:
zpool create tank mirror c0t0d0 c0t1d0 spare c0t2d0
Si un des disques échoue, le pool sera réduit à un état dégradé. le disque défectueux peut être remplacé avec:
zpool replace tank c0t0d0 c0t3d0
Une fois les donnée resilvered, le spare est automatiquement supprimé et de nouveau disponible. Le spare peut être supprimé de manière permanente avec:
zpool remove tank c0t2d0
Créer un pool avec les logs séparés:
zpool create pool mirror c0d0 c1d0 mirror c2d0 c3d0 log mirror c4d0 c5d0
Ajouter des disques cache à un pool:
zpool add pool cache c2d0 c3d0
Une fois ajoutés, les disques cache se remplissent avec le contenu de la mémoire principale. En fonction de la taille des disques, cela peut prendre des heures pour les remplir. La capacité et les lectures peuvent être supervisés avec iostat:
zpool iostat -v pool 5
Supprimer un périphérique log:
zpool remove tank mirror-2
récupérer un pool en faulted, récupérer un pool cache:
zpool clear -F data
sinon utiliser:
zpool import -F data

Codes de sortie

0 succès
1 Une erreur s'est produite
2 Options de ligne de commande invalide.

attributs

attribute type_______-_attribute value
Availability_________-____SUNWzfsu
Interface Stability _-Committed

^
16 janvier 2015

htmlpdflatexmanmd




zstreamdump

zstreamdump

Filtre de données dans le flux zfs send

Description

   Lit depuis la sortie de zfs send, et affiche les en-tête et des statistiques.

OPTIONS

-C Supprime la validation des checksums
-v Dump tous les headers, pas seulement les headers de début et de fin.

attributs

attribute type_______-_attribute value
Availability_________-____SUNWzfsu
Interface Stability _-____Uncommited