Provided by: bilibop-common_0.5.4_amd64 bug

NAME

       drivemap - show block devices in a tree of dependencies

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]
       [FILE]

       drivemap -h|--help
       drivemap [--debug] [-x|--set-x] [OPTIONS] [FILE]

DESCRIPTION

       drivemap is a shell script using the proc, sysfs and udev databases to display block devices in a tree of
       dependencies.   It  is  based  on  bilibop-common  shell  functions and supports device-mapper (including
       dm-crypt and LVM) and loop devices, with some limitations.  RAID devices and mhddfs filesystems  are  not
       supported. See the ENHANCEMENTS AND LIMITATIONS section below.

OPTIONS

       When  no  FILE  argument is invoked, the command is applied to all drives. If a FILE is given as argument
       and exists, then the command applies to the drive hosting it. FILE can be a regular file, a directory  or
       a block device.

       --debug
              Display  debug information on stderr. When this option is invoked, each called function prints its
              name. See also '--set-x'.

       -d, --drive
              Only show the drive node instead of its tree.

       -f, --backing-file
              Try to replace each loop device in the tree by its backing file. This can fail in some cases:  for
              example  on  DebianLive  systems, a loop device is associated to filesystem.squashfs from into the
              initramfs environment; the path of the backing file in /sys  is  not  updated  when  the  squashfs
              itself  becomes  the new root filesystem.  And so the filename stored in backing_file is obsolete,
              and will not be displayed here.

       -h, --help
              Print a summary of options on stdout and exit.

       -i, --info
              Display additional information about block devices. For drives, this includes the ID (as found  in
              /dev/disk/by-id),  and  the size (human readable). For other devices (partitions and virtual block
              devices), this includes the filesystem type ant its size.

       -m, --mark
              If a FILE is given as argument, append a mark (a star between parenthesis: (*)) to the name of the
              device  hosting  this FILE. Otherwise, append a mark to the name of the device hosting the current
              working directory.

       -n, --dm-name
              Replace  device-mapper  nodes  (/dev/dm-*)  by  device-mapper  names  (/dev/mapper/*),  which  are
              statically attributed and generally easier to understand.

       -p, --mountpoint
              Show the mountpoints of mounted devices, and show swap devices in use.

       -w N, --width=N
              Format  the  output on N columns. Can be used with '--info' and/or '--mountpoint'.  If N is not an
              integer or is greater than the number of columns of the screen, then the output will use the  full
              width  of  the screen. If this option is not used, then the default is to display the result on 70
              columns.

       -x, --set-x
              Display debug information on stderr. When this option is invoked, the shell script is set  as  -x,
              for more debug details. See also '--debug'.

ENHANCEMENTS AND LIMITATIONS

       drivemap is a part of the bilibop(7) project. It has initially been written to be applied to the external
       drive hosting the running system. By design, it don't support RAID devices, and will never support  them.
       Another design issue is that lvm(8) Volume Groups should contain only one Physical Volume. We assume that
       there is no sense to use several Physical Volumes on the same drive for the same Volume Group. Adopting a
       parent/child  mindview, we say that each device can have at most one parent but zero to several children.
       Since the script has been extended to be applied to all drives connected to  the  computer,  this  sounds
       like a bug.

       Unlike  the  lsblk(1) command, drivemap integrates loopback devices in the tree of dependencies. In fact,
       the question that can be asked is the following:
       " What will happen to the content of other physical or virtual block devices  if  I  dd(1),  shred(1)  or
       wipe(1) this one or this one ? "
       And  then  it  appears  that slaves and holders information in sysfs are not sufficient to organize block
       devices in a tree, or should be extended. For the same reason, logical partitions are shown as subdevices
       of primary extended partitions.

       Only  block devices whose contents is hosted by a physical disk are shown: this means if a loop device is
       associated to a file residing on a temporary filesystem (tmpfs, i.e. the RAM), this device  will  not  be
       shown. This is NOT a bug: as said by its name, drivemap builts and displays a 'map of drive(s)'.

EXAMPLES

       List the physical drives actually known by the kernel:

              drivemap -d

       Find the drive hosting the running system, and display its ID and size:

              drivemap -id /

       Show where is my current working directory on a disk with a complex partition scheme (LVM + LUKS + LVM):

              drivemap -min .

BUGS

       See the ENHANCEMENTS AND LIMITATIONS section above.

FILES

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

SEE ALSO

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

AUTHOR

       This manual page has been written by Bilibop Project <quidame@poivron.org>.