0

When creating an LV you can specify that (data for) that LV should only be written to a particular physical device (as opposed to letting the lvm put the data whereever it sees fit).

Eg.

lvcreate -L 100G -n lvOnSdb1 theVG /dev/sdb1

From lvcreate man pages :

To control which PVs a new LV will use, specify one or more PVs as position args at the end of the command line. lvcreate will allocate physical extents only from the specified PVs.

But how do you tell after the fact if that was done ie. if the LV has been restricted to specific PV(s) ?

EDIT This question arose out of a misunderstanding on my part - I was thinking of it as the LVM using actual media from various parts of its pool as it was required / as the LV was used whereas it assigns it up front to the LV when its sized/resized. So it is only ever using the PV(s) currently listed unless subsequently told to do otherwise.(thanks to Vojtech Trefny for clearing that up !)

1

You can use lvdisplay -m to display LV segments and PVs these segments are allocated on:

  --- Logical volume ---
  LV Name                root
...
 Segments               1
...
  --- Segments ---
  Logical extents 0 to 17916:
    Type                linear
    Physical volume     /dev/mapper/luks-dfcda59b-1322-4705-bb04-e09a72b2d678
    Physical extents    210601 to 228517

You can se my root logical volume has only one segment and is placed on my encrypted PV (I have only one physical volume, with multiple an LV spanning multiple PVs you would see more segments here).

Example for logical volume with two segments (which didn't fit to only one PV):

# lvdisplay -m test/lvol0
  --- Logical volume ---
  LV Name                lvol0
...
  Segments               2
...
  --- Segments ---
  Logical extents 0 to 123:
    Type                linear
    Physical volume     /dev/sdb
    Physical extents    0 to 123
   
  Logical extents 124 to 162:
    Type                linear
    Physical volume     /dev/sdc
    Physical extents    0 to 38

Edit: You can't tell whether the LV was manually placed on the PV(s) listed, the lvcreate optional argument affects only the "create" operation and has no effect on the created LV -- there is no difference between LV created with the PV specified and LV that just happens to be allocated on a specific PV by LVM. This doesn't affect future operations with commands like lvresize (you can also specify PVs for lvresize).

If you want to be able to check what lvm commands were run, you can set logging and log file in lvm.conf.

5
  • Cheers. It's actually the other part of the question I'm really interested in (sorry, my fault) ie. how can I tell if the LV is restricted to the PV(s) listed ie. was it created with a specified PV or PVs. I've edited the question.
    – Bob
    Nov 13 '21 at 14:53
  • 1
    There's no difference between LV manually placed on one PV and LV placed automatically there by LVM. Once it is created it doesn't matter how it was created, it makes no difference for future operations like lvresize. Nov 13 '21 at 14:59
  • 1
    Yes, if you specify a PV, lvcreate will create a logical volume that is allocated only on that PV. But that's it, the PV option applies only to the lvcreate command, this is not recorded in the metadata and if you want to be sure it stays on the PV all future operation (like lvresize) must also specify the PV. Nov 13 '21 at 15:11
  • 1
    Btw. check LVM thin provisioning which actually allows you to create (thin) LVs that area allocated on demand as you write data to them. But these are not allocated from the PVs directly but from a pool volume that needs to be created first (and the pool can be restricted to PVs). Nov 13 '21 at 15:19
  • What would also be interesting is how plain lvextend decides on which PV(s) to use, if none are given on the command line. Does it try to extend using the same PV, or does it just take whatever it thinks is the first free one even if not the same?
    – ilkkachu
    Nov 13 '21 at 15:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.