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

[Mark Woodward]

On 09/26/2011 10:17 PM, Bill Bogstad wrote:
> On Mon, Sep 26, 2011 at 9:45 PM, Mark Woodward<markw at mohawksoft.com>  wrote:
>> On 09/26/2011 07:17 PM, Edward Ned Harvey wrote:
>>> 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.
>> I don't think this is right. Running nagios on a snapshot would do nothing.
>> A snapshot is protected from change.
> This is neither true in the logical nor physical sense with LVM.   It
> was never true in a physical sense, in that the storage for the
> snapshot is slowly used up due to copy-on-write as applications write
> to the original copy of the filesystem.   It's not true in the logical
> sense because LVM snapshots have actually been read/write for quite a
> while.  A common usage pattern for this appears to be when you want
> multiple copies of essentially the same virtual machine image.
> You start with a single gold copy and then create writable snapshots
> for each virtual machine.
>
That is a use case, sure. That's not really the scenario that I was 
talking about, yes I know snapshots are read-write, but if they are 
short lived for backup, changes to the original do not affect the snapshot.

In your scenario, it is still no different than zfs. You still have a 
total number of changes in the snapshot from the original VM. Zfs is not 
magic, it will still need to store the changes and you still need to 
monitor the system to ensure you don't run out of space. With LVM you 
can set the the size of the snapshot to be the same as the VM, and then 
you don't need to worry about it.
> Bill Bogstad