linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sandeep Patil <sspatil@google.com>
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: Paul Lawrence <paullawrence@google.com>,
	Alasdair Kergon <agk@redhat.com>,
	Mike Snitzer <snitzer@redhat.com>,
	linux-doc@vger.kernel.org, kernel-team@android.com,
	Jonathan Corbet <corbet@lwn.net>,
	linux-kernel@vger.kernel.org, dm-devel@redhat.com,
	Shaohua Li <shli@kernel.org>
Subject: Re: [dm-devel] [RFC] dm-bow working prototype
Date: Sun, 2 Dec 2018 02:07:29 -0800	[thread overview]
Message-ID: <20181202100729.GT239052@google.com> (raw)
In-Reply-To: <alpine.LRH.2.02.1811151809380.25860@file01.intranet.prod.int.rdu2.redhat.com>

Hi Mikulas,

On Thu, Nov 15, 2018 at 06:15:34PM -0500, Mikulas Patocka 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.
> 

Thanks for that. We are as much sensitive to not duplicating functionality
and of course reliability of the implementation.

So we did spend considerable amount of time trying to make dm-snapshot work
for us (including the approach suggested here now). However, the additional
space needed to make dm-snapshot work in this situation is unfortunate and
won't work for Android. Especially given that we will be taking that space
away from the user all in one go too.

Anyway, I wanted to ask if there is any way we can make dm-snapshot work the
way dm-bow does? With patches is fine, we can work on that :).

I think Paul is planning to send a v2 with more description and the block
size fix that caused problems for others trying it out.

FWIW, dm-bow itself suffers from a mutex for each write that stalls for
longer when the write is to a block being modified (as opposed to a free
block being written to). We are hoping to iterate over that problem once the
general idea is acceptable to everyone.

Thanks for your help.

- ssp


> Mikulas

  reply	other threads:[~2018-12-02 10:07 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
2018-12-02 10:07               ` Sandeep Patil [this message]
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=20181202100729.GT239052@google.com \
    --to=sspatil@google.com \
    --cc=agk@redhat.com \
    --cc=corbet@lwn.net \
    --cc=dm-devel@redhat.com \
    --cc=kernel-team@android.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mpatocka@redhat.com \
    --cc=paullawrence@google.com \
    --cc=shli@kernel.org \
    --cc=snitzer@redhat.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).