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 snapshot cloning



On Oct 23, 2011, at 8:31 PM, markw at mohawksoft.com wrote:
> Both these snapshots are now "tracking" the real volume. Now, you use the
> COW data from the first snapshot and apply it to the second snapshot. This
> will create two identical snapshots. Both sparsely populated with only the
> differences between themselves and the real volume. The only drawback is
> that the two snapshots will contain duplicate COW data.


The "only" drawback is that you're treating LVM as if it were a file system.  Recall what I wrote yesterday about LVM biting off your face.  That's what's happening: LVM is gnawing on your nose right now.

An LVM volume is a dynamic disk partition, and LVM snapshots are transaction logs of the low level block changes.  These logs are presented to the OS as more block devices.  If you want to clone a snapshot then you have to treat it as the block device that it is.  What you really want is file system snapshots or a versioning file system.  LVM can accomplish neither because it's just a block device driver.

Unfortunately, neither of these exist for any of the main line file systems available in the Linux kernel.  ZFS isn't happening and Btrfs isn't read for production.  Both are under Oracle's thumb, and the other options are patches against the main kernel source that you have to apply and build yourself.

--Rich P.




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