DRIVEMAP(1) | Commandes de l'utilisatrice | DRIVEMAP(1) |
drivemap - montrer les périphériques bloc dans un arbre de dépendances
drivemap [-i|--info [-w|--width
N]] [-d|--drive] [FILE]
drivemap [-i|--info [-w|--width N]]
[-p|--mountpoint] [-f|--backing-file]
[-n|--dm-name] [-m|--mark] [FICHIER]
drivemap -h|--help
drivemap [--debug] [-x|--set-x] [OPTIONS]
[FICHIER]
drivemap est un script shell utilisant les informations de proc, sysfs et udev pour afficher les périphériques bloc dans un arbre de dépendances. Il est basé sur les fonctions shell de bilibop-common et supporte device-mapper (dont dm-crypt et LVM) et les périphériques boucle (loop) avec quelques limitations. Les périphériques RAID et les systèmes de fichiers mhddfs ne sont pas supportés. Voir plus bas la section AMÉLIORATIONS ET LIMITATIONS.
Quand aucun argument FICHIER n'est fourni, la commande est appliquée à tous les disques. Si un fichier FICHIER est donné comme argument et existe, alors la commande s'applique au disque contenant ce fichier. FICHIER peut être un fichier régulier, un répertoire ou un fichier spécial en mode bloc.
--debug
-d, --drive
-f, --backing-file
-h, --help
-i, --info
-m, --mark
-n, --dm-name
-p, --mountpoint
-w N, --width=N
-x, --set-x
drivemap fait partie du projet bilibop(7). Cette commande a été initialement écrite pour être appliquée au périphérique externe hébergeant le système en cours d'éxécution. Par son design, elle ne supporte pas les périphériques RAID et ne les supportera jamais. Un autre problème de design est que les Groupes de Volumes lvm(8) ne devraient contenir qu'un seul Volume Physique. Nous assumons qu'il n'y a pas de sens à utiliser plusieurs Volumes Physiques sur un même disque pour un même Groupe de Volumes. En adoptant une vue de l'esprit parent/enfant, nous disons que chaque périphérique peut avoir au plus un parent mais de zéro à plusieurs enfants. Depuis que le script a été étendu pour être appliqué à tous les disques connectés à l'ordinateur, cela sonne comme un bogue.
Contairement à la commande lsblk(1), drivemap
intègre les périphériques boucle (loop) dans l'arbre
des dépendances. En fait, la question qui peut être
posée est la suivante:
" Qu'est-ce qui se passera pour le contenu d'autres
périphériques physiques ou virtuels si je lance une commande
dd(1), shred(1) ou wipe(1) sur celui-ci ou
celui-là ? "
Et alors il apparaît que les informations contenues dans les fichiers
slaves et holders dans sysfs ne sont pas suffisantes pour
organiser les périphériques bloc en arbre, ou devraient
être étendues. Pour la même raison, les partitions
logiques sont montrées comme des sous-périphériques des
partitions primaires étendues.
Seuls les périphériques bloc dont le contenu est hébergé par un disque physique sont affichés: cela signifie que si un périphérique boucle est associé à un fichier se trouvant sur un système de fichiers temporaire (tmpfs, c'est à dire la RAM), ce périphérique ne sera pas montré. Ce n'est PAS un bogue: comme annoncé par son nom, drivemap construit et affiche une 'carte des disques' (map of drives).
Lister les lecteurs de disques physiques actuellement reconnus par le noyau:
Trouver le disque hébergeant le système en cours d'éxécution, et afficher son identifiant et sa taille:
Montrer où est mon répertoire de travail courant sur un disque avec un schéma de partitionnement complexe (LVM + LUKS + LVM):
Voir plus haut la section AMÉLIORATIONS ET LIMITATIONS.
/sys/class/block/*/holders
/sys/class/block/*/slaves
/sys/class/block/loop?*/loop/backing_file
bilibop(7), lsbilibop(8), lsblk(1), lvm(8), udev(7), udevadm(8)
Cette page de manuel a été traduite de l'anglais par Alexandre Martin <alemar@Safe-mail.net> dans le cadre du projet bilibop.
2012-05-22 | bilibop |