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

[richb at pioneer.ci.net (Rich Braun)]

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