5

I've been able to define a physical volume (LVM) in two ways:

  • Creating a 8e (Linux LVM type) partition and then # pvcreate /dev/sdb1
  • Usign pvcreate directly using a non-partitioned disk and then # pvcreate /dev/sdc <-- note the lack of number since there aren't any partitions.

My disks are not local, I use both scenarios: SAN provided LUN and VMware provided disks in different systems. We are testing LUN/vmware disk online resizing and everything went fine with the PVs defined using non-partitioned disks but with the partition layer it was impossible to hot-resize them using parted or fdisk.

My question is: why should I bother using 8e partitions if I can use raw disks for creating physical volumes and then resizing them online?

arle
  • 53
  • 4

2 Answers2

4

This was asked recently but it was in the context of local disks. In that situation, there is a good reason to use a partition table on the disk even if you only intend to make it a single big partition spanning the entire disk: documenting the fact that the disk is actually in use, thus preventing accidents.

I believe that the situation is different for managed disks, whether it is network block devices, paravirtualized disk images, SAN LUNs, iSCSI, etc...

In this case, I think you should feel free to use whole disks directly, for the following reasons:

  • Trying to use partition tables on these disks is apparently giving you trouble with resizing. Logical disks of this type can be dynamically resized in ways that physical disks never can. If it's giving you trouble, save yourself that trouble and don't do it.
  • These types of disks often do not correspond to physical hard disks and won't be subject to the same kinds of "this disk appears to be blank" accidents that physical disks can.
  • The logical disks is often backed by something that is already container-like: an outer partition, an LVM LV, a virtual block device in a storage cluster and an extra layer of partitioning is probably superfluous.
Community
  • 1
Celada
  • 43,173
  • 5
  • 96
  • 105
  • Excellent reply, Celada. That is the info I was looking for. Actually, I have sparse data from different sources but now I get the whole picture :) – arle Apr 28 '15 at 14:00
1

Does your disk partitioning tools recognise lvm? If they do Calada gives the right advice. I did a couple tests and file and fdisk on debian both do the right thing, but test the tools you use.

$ sudo file -s /dev/sd*
/dev/sda:  DOS/MBR boot sector
/dev/sda1: Linux rev 1.0 ext2 filesystem data, UUID=censored, volume name "boot"
/dev/sda2: LVM2 PV (Linux Logical Volume Manager), UUID: censored, size: censored
/dev/sda3: Linux/i386 swap file (new style), version 1 (4K pages), size censored pages, no label, UUID=censored
$ sudo fdisk /dev/sda2

Welcome to fdisk (util-linux 2.25.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

/dev/sda2: device contains a valid 'LVM2_member' signature, it's strongly recommended to wipe the device by command wipefs(8) if this setup is unexpected to avoid possible collisions.

Device does not contain a recognized partition table.
Created a new DOS disklabel with disk identifier 0x51e50433.

Command (m for help): q
hildred
  • 5,759
  • 3
  • 30
  • 43