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

[blu at nedharvey.com (Edward Ned Harvey)]

> From: discuss-bounces+blu=nedharvey.com at blu.org [mailto:discuss-
> bounces+blu=nedharvey.com at blu.org] On Behalf Of Rich Braun
> 
> Edward Ned Harvey wrote:
> > In LVM, if you want to do snapshots, you must first reserve all
> > the space that could possibly ever be used for the snapshot
> > differentials.
> 
> Actually, you don't.  A snapshot can be extended just like any other
logical
> volume.  What I do to manage storage resources is this:  over-allocate
when
> an
> application is first deployed.  Once I get a sense of how much is really
> required, then I can crank future deployments down to use more-realistic
> amounts.  Always use Nagios (or equivalent) to monitor remaining storage.
> Make sure the operations team knows how to respond to alerts, which in
> this
> case is a simple matter of typing "lvextend <foo>" -- a straightforward
> training exercise because the same command applies to normal ext4
> filesystems
> which run low on storage (the late shift will be told, if they can't find
> files to clean out, just run lvextend to add a few GB, followed by
resize2fs.)
> 
> So an example might be a 30GB volume for source-code control, for which I
> might over-allocate 15GB to a snapshot.  Once I saw that usage never goes
> past
> 2GB in a typical month, I might generate future snapshots with 4GB and set
> an
> alert to go off once it goes past 2GB.

So, this all serves to rather emphasize my point, which is to say...  
(LVM) Create snapshot, mount it, monitor it with nagios or whatever,
lvextend it, lvextend the filesystem, resize2fs, unmount and release
snapshot...
versus
(ZFS, Netapp, Volume Shadow Services, etc.)  Do nothing, and don't worry
about it.  It's all automatic and dynamic and just works.