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
