On 09/26/2011 10:17 PM, Bill Bogstad wrote:
On Mon, Sep 26, 2011 at 9:45 PM, Mark Woodward<[email protected]> 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
_______________________________________________
Discuss mailing list
[email protected]
http://lists.blu.org/mailman/listinfo/discuss
