On Thursday 27 July 2006 06:02am, Sander Smeenk wrote: > Hello list! > > I've recently subscribed here as i have some questions about LVM, > particularly the performance impact of LVM on disk IO. > > I'm a happy LVM user, on my workstation at home i've used it for a long > time. No special setups or anything, but it's nice to be able to resize > partitions on the fly, or have a number of disks act as one huge disk... > > So, when I had to reinstall all servers for the company I work for, i > decided to use LVM for the same reasons stated above. But now i wonder: > Does LVM have any impact on disk IO? Are there any tests done on this > subject? > > I couldn't really find any on the internet. Most of the things you find > are implementation issues and 'how does it work' stuff ;-) > > I'm running LVM2 (2.02.06) on Debian 'sid' (unstable, but i hate that word) > using linux kernels 2.6.17.xx. > > For example, one of my servers has 4x 34gb SCSI disks and 2x IDE disks. > One of the IDE disks has a 250MB boot partition, the rest is LVM > partition, the other IDE disk has one big LVM partition, same goes for > the 4 SCSI disks. > > Then i made a scsi_vg01, with all the scsi disks and a ide_vg01 with all > the ide disks, and started lvcreating "partitions" inside those vg's. > That's basically how i set up LVM on all of my servers. Some servers > have different disk-configurations though... Any particular reason to not include all the disks in a single VG? Also, this setup will actually leave you more vulnerable to single disk failures. I would *highly* recommend using RAID to aggregate your disks together, then use LVM on top of that to make things manageable. > Can anyone shed any light on this approach? Are there impacts on > performance of read / write actions? Any information is welcomed. When you try to read or write to a VG, the LVM code is used by the VFS layer in the Kernel to decide the physical device/track/sector address to send the I/O operation to. The only "extra" LVM I/O done is when you are (re)configuring LVM. Things like creating, resizing & deleting an LV require a little bit of disk I/O, of course. Other than the small amount of overhead when using snapshot volumes, there isn't any other impact on I/O performance. However, I wonder if the LVM address look-up code is better than, equal to or any worse than that for a plain block device (e.g. partition, loopback mounted file, etc.). If there is a statistically relevent delta there, I think it would only impact I/O latency and even then, it couldn't be much. When booting your system, it does have to take a moment and "vgscan" for VGs. This is pretty fast, but it adds a second or two to your bootup time. That's all I can think of off the top of my head. HTH. -- Lamont R. Peterson <peregrine@OpenBrainstem.net> Founder [ http://blog.OpenBrainstem.net/peregrine/ ] GPG Key fingerprint: 0E35 93C5 4249 49F0 EC7B 4DDD BE46 4732 6460 CCB5 ___ ____ _ _ / _ \ _ __ ___ _ __ | __ ) _ __ __ _(_)_ __ ___| |_ ___ _ __ ___ | | | | '_ \ / _ \ '_ \| _ \| '__/ _` | | '_ \/ __| __/ _ \ '_ ` _ \ | |_| | |_) | __/ | | | |_) | | | (_| | | | | \__ \ || __/ | | | | | \___/| .__/ \___|_| |_|____/|_| \__,_|_|_| |_|___/\__\___|_| |_| |_| |_| Intelligent Open Source Software Engineering [ http://www.OpenBrainstem.net/ ]
Attachment:
pgpPqySyneKZ9.pgp
Description: PGP signature
_______________________________________________ linux-lvm mailing list linux-lvm@redhat.com https://www.redhat.com/mailman/listinfo/linux-lvm read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/
