<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small">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.</div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small">Thanks,</div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif;font-size:small">Paul</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Nov 15, 2018 at 3:15 PM Mikulas Patocka <<a href="mailto:mpatocka@redhat.com">mpatocka@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
On Mon, 29 Oct 2018, Paul Lawrence wrote:<br>
<br>
> <br>
> > The snapshot target could be hacked so that it remembers space trimmed<br>
> > with REQ_OP_DISCARD and won't reallocate these blocks.<br>
> > <br>
> > But I suspect that running discard over the whole device would degrade<br>
> > performance more than copying some unneeded data.<br>
> > <br>
> > How much data do you intend to backup with this solution?<br>
> > <br>
> > <br>
> We are space-constrained - we will have to free up space for the backup before<br>
> we apply the update, so we have to predict the size and keeping usage as low<br>
> as possible is thus very important.<br>
> <br>
> Also, we've discussed the resizing requirement of the dm-snap solution and<br>
> that part is not attractive at all - it seems it would be impossible to<br>
> guarantee that the resizing happens in a timely fashion during the (very busy)<br>
> update cycle.<br>
> <br>
> Thanks everyone for the insights, especially into how dm-snap works, which I<br>
> hadn't fully appreciated. At the moment, and for the above reasons, we intend<br>
> to continue with the dm-bow solution, but do want to keep this discussion<br>
> open. If anyone is going to be at Linux Plumbers, I'll be presenting this work<br>
> and would love to chat about it more.<br>
<br>
dm-snapshot took 9 years to fix the last data corruption bug (2004-2013 - <br>
the commit e9c6a182649f4259db704ae15a91ac820e63b0ca).<br>
<br>
And with the new target duplicating the snapshot functionality, it may be <br>
the same.<br>
<br>
Mikulas<br>
</blockquote></div>