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 <mpato...@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 >
-- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel
