Provided by: bilibop-common_0.5.0_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>.