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 | Blog | 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



Bill Bogstad wrote:
> Any snapshot implementation is going to require two different blocks
> on disk for every block written while the snapshot exists.  (i.e. the
> original contents and the new contents of each virtual block which
> has been written)
>
> As I understand it, LVM uses the original location for new versions
> of each block while the original contents of that location are
> written to newly allocated blocks.  Thus you get two writes (and a
> read) the first time any block is written.
>
> The opposite approach (new contents are written to newly allocated
> blocks) only require a single write.
>
> The problem occurs when you go to delete a snapshot. With LVM, you
> just deallocate the storage where the old data was copied too and do
> some meta-data cleanup.   With the alternative approach, deleting a
> snapshot is more complicated.  Assuming that you want to actually
> release the storage where all of the new data was written while a
> snapshot was turned on, you have to copy all of that data back to the
> corresponding locations in the originally allocated space.  (i.e. a
> read and a write.)  So either design requires the same total number
> of IO operations...

That last paragraph is incorrect. (I'm surprised Ed didn't chime in on
this.)

A ZFS snapshot is essentially metadata pointing to "stale" blocks. If
you want to get rid of the snapshot, you just delete the head node in
the metadata, and poof, it's gone.

If you've ever played with rsync snapshots, the principle is the same,
only at the file level instead of the block level. With rsync snapshots
you have a set of real files, and then one or more directory trees that
consist of nothing but symlinks to the real files, with the exception of
any files that have changed.

Modified files are written as real files, while unmodified files are
written as a symlink.

When you delete a snapshot, you mostly remove symlinks, and a few real
directory entries. Essentially snapshots mostly consist of metadata,
plus a bit of stale data.

ZFS snapshots are light weight, fast to create or remove, and space
efficient.

As a non-storage professional, my option is that LVM snapshots were
glued-on as an afterthought, and have limited applications. ZFS
snapshots (and similar in NetApp filers) were designed into the
low-level file system architecture.

Generally speaking, the whole LVM concept seems quaint and requires a
lot of manual management. I haven't deployed it on a system since 2006.
Unfortunately, there aren't good alternatives for it on Linux.

 -Tom

-- 
Tom Metro
Venture Logic, Newton, MA, USA
"Enterprise solutions through open source."
Professional Profile: http://tmetro.venturelogic.com/



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