Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

When multiple storage virtualization systems are used together, it can be complicated and time-consuming to gain an understanding of the structure of the various relationships involved. What tools are available for diagramming and summarising these relationships?

The case I am particularly interested in is Linux's LVM and LUKS. I have a system where these are layered on top of one another. My goal was to draw a block diagram, with layers as follows (simplifiying a little to keep out irrelevant complications):

  1. LVM logical volume (LV)
  2. LVM volume group (VG)
  3. LUKS partition == LVM physical volume (PV)
  4. Physical partition
  5. Physical disk

Note that although in general, VGs form a many-to-many relationship between LVs and PVs, my case was simpler because each VGs was associated only with a single PV.

The block diagram was to be labelled with information such as physical disk device file names, PV, VG, and LV names, the device-mapper device names, and the disk UUIDs, where available.

I just drew that block diagram. I found that I used 12 sources of information, along with prior knowledge of the system, and watching the system change over time as I ran the cryptsetup and mount commands. Drawing it was a painful and time-consuming iterative process of building up knowledge, reminding me of a certain kind of logic problem. Here are some of the commands I used:

ls -l /dev/mapper/*
ls -l /dev/disk/by-uuid/*
dmsetup info
ls -l /dev/mapper/<LV name>
cat /etc/fstab
cat /etc/crypttab
fdisk -l /dev/<physical disk device name>

What tools are available for producing summaries of this kind of storage virtualization system, and Linux-specific systems like LVM and LUKS in particular? I would happily settle for plain text relational listings in place of block diagrams.

In my case, there were some additional complications. I'll describe these just to illustrate how it can get more complicated, but note that the situation above was complicated enough to make it time-consuming to draw the block diagram just for the part of my system that is as described above. I'm aware that the problem could be simplified by removing these complications, so let's please not waste space on that.

One complication was that I also have a number of old partitions in which the LUKS/LVM layering is opposite to that described above, i.e.:

(physical partition == LVM PV) -> VG -> LV -> LUKS encrypted device -> LUKS plaintext device

instead of:

physical partition -> LUKS encrypted device -> (LUKS plaintext device == LVM PV) -> VG -> LV

In addition, one LUKS encrypted device was mislabelled, suggesting that it was on a different physical disk that it was in reality!

Obviously there could be other complications too, most obviously where a single volume group is associated with multiple physical volumes. In that case, I would want multiple block diagrams (two in the simple case, more if the layering is more complicated).

share|improve this question

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.