On Mon, Sep 26, 2011 at 12:15 PM, Rich Braun <[email protected]> wrote:
> The open-source LVM manager in Linux provides excellent _read_ performance. > Where it suffers relative to commercial products (NetApp, Isilon, et al) is > the _write_ performance. > > In this thread, a criticism is leveled that it eats up disk space. Well, > if > you were to allocate 2x the storage of your runtime volume, you'd never run > out of space on a given snapshot. With 2TB drives dropping under $100 > these > days, I hardly see that space is much of a criterion when planning to use > LVM > or not. If you want to create a lot of active snapshots, then this might > be a > consideration. > > Each active snapshot drops write performance due to the copy-on-write > implementation. (I'm not sure why the open-source product persists in this > requirement, perhaps there are no active developers looking into this > problem--there are other ways to attack this problem which would provide > better performance. Future versions of LVM will someday drop the > copy-on-write implementation.) > > But as some have noted here, this is only a problem for active filesystems > that see a lot of scattered writes. Compare an SVN server with a MySQL > server. The impact of copy-on-write is far greater on a large (50GB+) > InnoDB > database tied to an active social-networking site than on a modest (10GB) > source-code repository. If frequently-updated files are a small percentage > of > your overall dataset, then snapshots are not much of a performance > factor--especially (as is typical in case of developer teams) most of the > activity causes updates to the same files. > > There are many applications where the performance hit is negligible, or at > least outweighed by the benefit of fast file recovery or other capabilities > that snapshots provide. > > -rich > > > _______________________________________________ > Discuss mailing list > [email protected] > http://lists.blu.org/mailman/listinfo/discuss > As far as eating disk space, this depends on how many changes happen between when you take the snapshot and when you release it. If you have a 500GB drive, 400GB allocated to the volume, and 100GB free for snapshots, then you can alter your data 4x (assuming you're using 100% available space). The math isn't exact but it's usually fairly close. There are also commands you can use to monitor the free space. >From what I've seen when I used LVM it's not meant to keep the snapshot longterm, it's meant to grab a picture of the contents at a point in time without having other processes change the files then move it to where you can do something else with it. So a perfect example is a backup of MySQL. You cannot copy the MySQL files why MySQL is running. So shutdown MySQL, take a snapshot, start MySQL, copy the snapshot to wherever you want since it won't affect the running version, when the copy is done stop MySQL, release snapshot, start MySQL again, then go over to your other system and work with that copy you made. The problem I've seen with LVM is that people are running it with one or two physical drives and they're complaining about performance problems. In the past I've built a database that had a SAN backend (numerous physical drives), the volume was managed by LVM and the physical drives had enough spindles to deal with read/write performance even since there was a higher than normal load. Think of it this way, without LVM if your drives started having more IOPS, how do you solve the latency issue? Add more drives. Matthew Shields Owner BeanTown Host - Web Hosting, Domain Names, Dedicated Servers, Colocation, Managed Services www.beantownhost.com www.sysadminvalley.com www.jeeprally.com Like us on Facebook <http://www.facebook.com/beantownhost> Follow us on Twitter <https://twitter.com/#!/beantownhost> _______________________________________________ Discuss mailing list [email protected] http://lists.blu.org/mailman/listinfo/discuss
