[Discuss] lvm snapshot cloning

[markw at mohawksoft.com (markw at mohawksoft.com)]

> On Oct 24, 2011, at 7:41 AM, markw at mohawksoft.com wrote:
>>
>> 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.
>
> That's where I say that you are mistaken, because it isn't, not really.
> It does a fair job of pretending but once you get deep into it you'll find
> it there grinning, waiting to bite your face off.

Well, I've spent a lot of my limited spare time the last few weeks really
getting down low. I think you are mistaken.

There are two issues with LVM, well actually one, and one with snapshots.

With LVM, it does not transparently detect and reroute around bad blocks.
This would be a cool feature, but since RAID is supported, it is an issue
that can be worked around.

With snapshots, its a bad design in that all snapshots receive all COW
blocks. So if you have two snapshots with the same basic content, there
will be duplicative data. This means that you have to allocate enough
space for the changes N times depending on the number of snapshots.

Other systems, chain snapshots so that at any time, only one snapshot is
receiving COW data, and the subsequent snapshots only forward reference.

Anyway, LVM snapshots are workable for the most part.
>
>
>> Not really true, LVM snapshots are a copy-on-write devices. Yes, there
>> is
>> an exception log behind them to map the COW data.
>
> You're quibbling over implementation.  In practice, LVM snapshots work
> like ever-expanding transaction logs that are presented to the VFS layer
> as block devices.

Yes.
>
>
>> Why? Snapshots are read/write and work fine.
>
> They don't.  See the previous discussion about LVM snapshot performance
> degradation.

The performance degradation is transient. It is only incurred at the time
of COW, then it is mostly trivial. The problem with many of the benchmarks
is that they basically measure the worst case COW performance which is
known as an issue.

While not guaranteed, most applications do not create a large number of
COW pages all at once. There is a momentary hit periodically, but
performance decrease, on average, is minimal.

>
>
>> 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.
>
> Okay, it's a *fancy* block device driver.  Because at the end of the day,
> when it comes to doing any real work on it, the kernel presents LVM
> volumes just like it does raw disk partitions which are (pause) block
> devices.  This is a lot of why the features that you want will never be
> implemented.

I don't understand this viewpoint. Block devices are far far easier to
implement the sort of features needed. A block device has fewer
constraints and has more ordered access than would a higher level file
system.

>
> I'm not saying that this is a failing.  In fact, this is central to LVM's
> versatility.  You can put practically any file system on an LVM volume
> specifically because it is a block device.  For example, I could put a
> FreeBSD domU on a Linux dom0 and give that domU an entire LVM volume to
> itself.  FreeBSD doesn't care because the volume is just a block device.
> I can stick DRBD underneath that volume and replicate it block-for-block
> to my redundant dom0 because it is a block device.  Linux and Xen don't
> care because (pause) the volume is just a block device.  I could never do
> something like this with AdvFS, and I expect that doing it with zpools
> would be more work than lvcreate, add device to config file, boot
> installer image.
>
> This is what I'm on about.  If you treat LVM volumes as block devices then
> you can do some amazing things with them.  If you treat them as something
> else then you're going to have problems.

They are being treated as a block device, but the capabilities as
advertised can be used.
>
> --Rich P.
>
> _______________________________________________
> Discuss mailing list
> Discuss at blu.org
> http://lists.blu.org/mailman/listinfo/discuss
>