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

[matt at mattshields.org (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.