Re: Multisnap / dm-thin

[Joe Thornber <thornber@redhat.com>]

On Wed, Jan 18, 2012 at 11:35:40AM +0100, Spelic wrote:
> Hello all,
> I would need the multisnap feature, i.e., the ability to make many
> snapshots without high performance degradation...
> I saw it mentioned around, but it does not seem to be in the kernel
> yet. Is it planned to be introduced? Is there an ETA?
> 
> Note that I am not very fond of the new dm-thin which is planned to
> have a multisnap-equivalent feature, because of the fragmentation it
> will cause (I suppose a defragmenter is long way to come). Not
> having fragmentation is the reason for using blockdevices instead of
> loop mounted files after all isn't it?

The point of multisnap is that blocks of data are shared between
multiple snapshots (unlike the current single snap implementation).
Saving both disk space, and probably more importantly, redundant
copying.  As such I struggle to see why you think it's possible to do
this and keep all the data contiguous.  Both Mikulas' multisnap, and
my thinp, use btrees to store the metadata, and allocate data blocks
on a first come first served basis.

Fragmentation is a big concern; but until I have a good idea what real
world usage patterns for thinp are I'm a bit short of data to base any
improvements to the allocator on.  If you want to help I'd love to
know your usage scenario, and the slow down you're observing as the
pool ages.

As far as a defragmenter goes.  My first approach will be allowing
people to set a 'copy-on-read' flag on thin devices that they feel are
too fragmented.  This will then trigger the current machinery for
breaking sharing - but reallocating according to the _current_ io
usage pattern.  This should be a very small change, when I see
real world fragmentation, I'll implement it.

Maybe your requirement is for the origin to be a preexisting,
contiguous device?  In which case see the other discussion thread with
Ted Tso.

- Joe