[dm-devel] [RFC] dm-bow working prototype

[Paul Lawrence]

Understand. I will be looking for a way to upstream the functionality we
need, but will spend time trying to work out how to integrate it into
dm-snap or leverage dm-snap in some other way to avoid duplication.

Thanks,

Paul

On Thu, Nov 15, 2018 at 3:15 PM Mikulas Patocka <mpatocka at redhat.com> wrote:

>
>
> On Mon, 29 Oct 2018, Paul Lawrence wrote:
>
> >
> > > The snapshot target could be hacked so that it remembers space trimmed
> > > with REQ_OP_DISCARD and won't reallocate these blocks.
> > >
> > > But I suspect that running discard over the whole device would degrade
> > > performance more than copying some unneeded data.
> > >
> > > How much data do you intend to backup with this solution?
> > >
> > >
> > We are space-constrained - we will have to free up space for the backup
> before
> > we apply the update, so we have to predict the size and keeping usage as
> low
> > as possible is thus very important.
> >
> > Also, we've discussed the resizing requirement of the dm-snap solution
> and
> > that part is not attractive at all - it seems it would be impossible to
> > guarantee that the resizing happens in a timely fashion during the (very
> busy)
> > update cycle.
> >
> > Thanks everyone for the insights, especially into how dm-snap works,
> which I
> > hadn't fully appreciated. At the moment, and for the above reasons, we
> intend
> > to continue with the dm-bow solution, but do want to keep this discussion
> > open. If anyone is going to be at Linux Plumbers, I'll be presenting
> this work
> > and would love to chat about it more.
>
> dm-snapshot took 9 years to fix the last data corruption bug (2004-2013 -
> the commit e9c6a182649f4259db704ae15a91ac820e63b0ca).
>
> And with the new target duplicating the snapshot functionality, it may be
> the same.
>
> Mikulas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20181119/436dee6e/attachment.htm>