[Discuss] LVM Re: A really interesting chain of functionality

[Matt Shields]

On Mon, Sep 26, 2011 at 12:15 PM, Rich Braun <richb at pioneer.ci.net> 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
> Discuss at blu.org
> 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>