NOM¶

drivemap - montrer les périphériques bloc dans un arbre de dépendances

SYNOPSIS¶

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]

DESCRIPTION¶

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.

OPTIONS¶

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

AMÉLIORATIONS ET LIMITATIONS¶

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).

EXEMPLES¶

Lister les lecteurs de disques physiques actuellement reconnus par le noyau:

drivemap -d

Trouver le disque hébergeant le système en cours d'éxécution, et afficher son identifiant et sa taille:

drivemap -id /

Montrer où est mon répertoire de travail courant sur un disque avec un schéma de partitionnement complexe (LVM + LUKS + LVM):

drivemap -min .

BOGUES¶

Voir plus haut la section AMÉLIORATIONS ET LIMITATIONS.

FICHIERS¶

/sys/class/block/*/holders
/sys/class/block/*/slaves
/sys/class/block/loop?*/loop/backing_file

VOIR AUSSI¶

bilibop(7), lsbilibop(8), lsblk(1), lvm(8), udev(7), udevadm(8)

AUTEUR¶

Cette page de manuel a été traduite de l'anglais par Alexandre Martin <alemar@Safe-mail.net> dans le cadre du projet bilibop.