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. -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
