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 |
> 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. Why are you saying this? LVM is designed for much of this. The strategy described is perfectly valid within the context of read/write snapshots. > > An LVM volume is a dynamic disk partition, and LVM snapshots are > transaction logs of the low level block changes. Not really true, LVM snapshots are a copy-on-write devices. Yes, there is an exception log behind them to map the COW data. > 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. Why? Snapshots are read/write and work fine. > 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. Its a bit more than a block driver. Yes, it is presented to the higher levels of the OS as a block driver, but it does remapping of blocks, it has modules for raid, etc. > > 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. Which is why I'm exploring LVM. > > --Rich P. > > _______________________________________________ > Discuss mailing list > Discuss at blu.org > http://lists.blu.org/mailman/listinfo/discuss >
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |