[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fba91b2e-4b2e-8daf-ff64-a12c9139cada@google.com>
Date: Mon, 29 Oct 2018 09:51:48 -0700
From: Paul Lawrence <paullawrence@...gle.com>
To: Mikulas Patocka <mpatocka@...hat.com>
Cc: Alasdair Kergon <agk@...hat.com>,
Mike Snitzer <snitzer@...hat.com>, linux-doc@...r.kernel.org,
kernel-team@...roid.com, Jonathan Corbet <corbet@....net>,
linux-kernel@...r.kernel.org, dm-devel@...hat.com,
Shaohua Li <shli@...nel.org>
Subject: Re: [dm-devel] [RFC] dm-bow working prototype
> 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.
Powered by blists - more mailing lists