[Linux-PowerEdge] Extremely poor performance with LVM vs. RAW disc
L. A. Walsh, Tlinx Solutions
dell at tlinx.org
Tue Nov 6 16:08:01 CST 2012
> If you have a virtual disk that uses partitions then the partitions are fixed to the size of the volume as it was originally created. It will not see the additional disk space on the volume unless you delete the partition and recreate it, thereby including the new space. This is simply not necessary with whole disk LVM.
I may be confused, but if you have a whole disk lvm, how would you
And what do you mean by whole disk lvm?
I have tried whole-disk formats and found they don't provide any real
benefit and do provide a deficit.
That is -- when you look at the hard disk with a partition editor -- it
will tell you the disk is unformatted.
You can ask lvm to scan all physical volumes for lvm's, but that
involves it going out and doing physical scanning
to see what lines up. if your lvm header is messed up, lvm may not
detect it. Both lvm and disk-partitioning have
backup tables, but the table for lvm is optional and not located at a
well-known location (it's configurable).
The backup tables of the partition editors are in fixed location as well
as providing identity information for the OS.
There is no reason lvm on top of, say, parted-guid partitions, should be
any slower than on a raw disk except on
initial boot -- where it needs to lookup 1 indirect table. But after
that, the lvm's partitions start and ends are kept
in memory and the kernel has already converted them to absolute blocks
on the block device, so there should
be no speed difference.
I used to think there might be until I realized that if the blocks were
not at fixed addresses, lilo wouldn't work --
as it records the fixed-block numbers for each image in a partition --
no matter if it is on lvm, raw or in a file system
or in RAID (as long as the RAID is loaded BEFORE lilo -- i.e. BIOS-SW
RAID or HW RAID)...
Lilo wouldn't have any OS SW loaded to support translations that could
take up more time.
All you have to do is confused an unpartitioned disk with an unformatted
disk once, and you'll realize the benefit
of a partition table -- even if it contains only 1 disk-sized partition
that is all lvm...
As for saying "we're all good admins and nothing imperfect ever
happens", .. you are joking, right?
Don't suppose you ever met Ms. Murphy... (she picks up where Mr. Murphy
lets you by)... she's so willing
to prove your worst nightmares... only for your own benefit, of
course!...*gulp*...good to keep her placated as
much as possible.
What constraints do partitions put on you?...(using guid...not old
I concure with XFS as the cure to all evil, (hyperbole, anyone?)...but
does it's magic on partitions
and whole disks equally well -- ..
And with partitions -- I have extended XFS .. you make a partition
larger, and tell XFS... "growfs"...
and it gets bigger. NTFS does too. Dunno...does extX or others have
> However, I will concede one thing *against* whole disk LVM and that is that whole disk volumes don't work so well in multi-boot environments or during new kickstarts. This is because it looks to the OS that the disk has *NOT* been partitioned and so if care is not take you *COULD* wipe out the PV properties, however, we're all good admins of course so that never happens. At least so far it hasn't happened to me. That said, I still believe whole disk logical volumes remove many constraints that partitions put on you for storage management. The whole point is to use logical volume manager to slice and dice the disk, not partitions + volume manager to slice and dice them.
More information about the Linux-PowerEdge