Provided by: bilibop-common_0.5.0_i386 bug


       drivemap - show block devices in a tree of dependencies


       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]


       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.


       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.

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

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


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


       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 .


       See the ENHANCEMENTS AND LIMITATIONS section above.




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


       This    manual    page    has   been   written   by   Bilibop   Project