From: Mikulas Patocka <email@example.com> To: Paul Lawrence <firstname.lastname@example.org> Cc: Alasdair Kergon <email@example.com>, Mike Snitzer <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org, Jonathan Corbet <email@example.com>, firstname.lastname@example.org, email@example.com, Shaohua Li <firstname.lastname@example.org> Subject: Re: [dm-devel] [RFC] dm-bow working prototype Date: Thu, 15 Nov 2018 18:15:34 -0500 (EST) [thread overview] Message-ID: <alpine.LRH.email@example.com> (raw) In-Reply-To: <firstname.lastname@example.org> 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 prev parent reply other threads:[~2018-11-15 23:15 UTC|newest] Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-10-23 21:23 Paul Lawrence 2018-10-23 22:18 ` Alasdair G Kergon 2018-10-24 18:42 ` Paul Lawrence 2018-10-24 19:24 ` [dm-devel] " Mikulas Patocka 2018-10-25 0:01 ` Alasdair G Kergon 2018-10-25 10:20 ` Bryn M. Reeves 2018-10-25 17:23 ` Paul Lawrence 2018-10-26 20:03 ` Mikulas Patocka 2018-10-29 16:51 ` Paul Lawrence 2018-11-15 23:15 ` Mikulas Patocka [this message] 2018-12-02 10:07 ` Sandeep Patil 2018-10-25 16:30 ` MegaBrutal 2018-10-25 18:13 ` Paul Lawrence 2018-10-25 21:15 ` Wols Lists 2018-10-25 21:43 ` [dm-devel] " Darrick J. Wong
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=alpine.LRH.email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --subject='Re: [dm-devel] [RFC] dm-bow working prototype' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).