DRIVEMAP(1) | User commands | DRIVEMAP(1) |
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.
--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 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:
Find the drive hosting the running system, and display its ID and size:
Show where is my current working directory on a disk with a complex partition scheme (LVM + LUKS + LVM):
See the ENHANCEMENTS AND LIMITATIONS section above.
/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)
This manual page has been written by Bilibop Project <quidame@poivron.org>.
2012-05-22 | bilibop |