Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



> From: Mark Woodward [mailto:markw at mohawksoft.com]
> 
> I don't think this is right. Running nagios on a snapshot would do
> nothing. A snapshot is protected from change. Typically, what you would
> do is this:
> 
> Create a volume, monitor it, create a snapshot to get a "point in time"
> image of the volume, backup the snapshot, and then remove the snapshot.
> 
> Pretty much the same model as the other things.

My memory is similar to what Matt wrote.  Suppose you have a 400G volume,
and you use a 100G volume for snapshots.  You create a snapshot, and then
the 400G is frozen, while all new changes get written to the 100G.  When
100G runs out, the snapshot disappears.  I don't know if you have to monitor
available usage using df on the pool, df on the snapshot, or lvdisplay or
some other command, but I'm sure there's a command that will let you monitor
the amount of space remaining in your snapshot device.  It is not allocated
or resized dynamically.  If you want to make it reallocate dynamically,
you're doing some pretty crazy scripting which is not necessary on other
snapshot systems (zfs etc)




BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org