Why not have a look at the snapshots section of the LVM-HOWTO?
LVM snapshots are your basic "copy on write" snapshot solution. The snapshot is really nothing more than asking the LVM to give you a "pointer" to the current state of the filesystem and to write changes made after the snapshot to a designated area.
LVM snapshots "live" inside the volume group hosting the volume subject to the snapshot-- not another volume. Your statement "...lots and lots of unallocated freespace not it the partition" makes it sound like your thinking is that the snapshots "live" outside the volume group subject to snapshot, and that's not accurate. Your volume group lives in a hard disk partition, and the volume being subject to snapshot and any shapshots you've taken live in that volume group.
The normal way that LVM snapshots are used is not for long-term storage, but rather to get a consistent "picture" of the filesystem such that a backup can be taken. Once the backup is done, the snapshot is discarded.
When you create an LVM snapshot you designate an amount of space to hold any changes made while the snapshot is active. If more changes are made than you've designated space for the snapshot becomes unusable and must be discarded. You don't want to leave snapshots laying around because (a) they'll fill up and become unusable, and (b) the system's performance is impacted while a snapshot is active-- things get slower.
Edit:
What Microsoft Volume Shadow Copy Services and LVM snapshots do aren't too tremendously different. Microsoft's solution is a bit more comprehensive (as is typically the case with Microsoft-- for better or for worse their tools and products often seek to solve pretty large problems versus focusing on one thing).
VSS is a more comprehensive solution that unifies support for hardware devices that support snapshots and software-based snapshots into a single API. Further, VSS has APIs to allow applications to be made quiescent through the snapshot APIs, whereas LVM snapshots are just concerned with snapshots-- any quiescing applications is your problem (putting databases into "backup" states, etc).
As of GNU coreutils 7.5 released in August 2009, sort
allows a -h
parameter, which allows numeric suffixes of the kind produced by du -h
:
du -hs * | sort -h
If you are using a sort that does not support -h
, you can install GNU Coreutils. E.g. on an older Mac OS X:
brew install coreutils
du -hs * | gsort -h
From sort
manual:
-h, --human-numeric-sort compare human readable numbers (e.g., 2K 1G)
Best Answer
Remember that you can resize snapshots on the fly, e.g. with lvextend. So you can give them a sensible initial size and then grow them whenever they get too ful.
This can even be done automatically: Using dmeventd and setting this in lvm.conf:
Autoextending does not work instantly, it takes a few seconds for dmeventd to react ... and 50% fill grade and 50% growth is pretty harsh, but for testing with a very small snapshot (and thus rapidly filling the snapshot with data) they are needed.
no need to be root to write files
while this is running, start
The sleep in the writing is needed to let dmeventd catch up --- IIRC it only checks every 10 seconds.
Back to our output:
Watch it grow ...