Re: kvm-83 write performance raw

[Mark van Walraven <markv@netvalue.net.nz>]

Hi Paolo,

Sorry, list - getting a bit off-topic but I'll include because it might
be of general interest for kvm users ...

On Wed, Mar 04, 2009 at 11:28:18PM +0100, Paolo Pedaletti wrote:
> ok, I can understand this
> but on a big multimedia-file partition an "opportune" read-ahead could  
> be useful (to set with blockdev)

Sure.  Adjust and measure for your average and worst-case workload.
I expected a moderate read-ahead to help on the storage serving my kvm
hosts, but in practice it caused painful latency spikes.

> I use LVM extensively so can you explain how can you achieve alignments  
> between lvm and filesistem? and how to check it?

Your links contain good material on this.  My comments are:

When you can, don't use a partition table but make the whole disk a PV.
Otherwise, watch that your partitions are properly aligned.

Use '--metadatasize 250k' arguments with pvcreate (the size is always
rounded up the next 64KB boundary so 250k ends up 256KB, '--metadatasize
256k' would result in 320KB).

'pvs -o+pe_start' and 'dmsetup table' will show your PV and LV offsets.

If you use image files, you probably don't want them to have holes in
them, or they will likey fragment as the holes are filled.  I expect
qcow2 images internally fragment?  Read-ahead on a fragmented image file
will really hurt.

Ext2 doesn't seem very sensitive to alignment.  I haven't played with
aligning ext3's journal.  (Speculation: a deliberately-wrong stride could
be interesting if inode lookups are a seek away from their data block
and your RAID is clever about splitting seeks between mirror drives.)

RAID controllers can have their own sector offsets and read-aheads.

Using disk type='block' avoids the host filesystem overhead altogether.

Regards,

Mark.