[dm-devel] dm-clone: Request option to send discard to source device during hydration

Mike Snitzer snitzer at kernel.org
Tue Mar 28 16:20:18 UTC 2023


On Mon, Mar 27 2023 at  4:24P -0400,
Gwendal Grignou <gwendal at chromium.org> wrote:

> On ChromeOS, we are working on migrating file backed loopback devices
> to thinpool logical volumes using dm-clone on the Chromebook local
> SSD.
> Dm-clone hydration workflow is a great fit but the design of dm-clone
> assumes a read-only source device. Data present in the backing file
> will be copied to the new logical volume but can be safely deleted
> only when the hydration process is complete. During migration, some
> data will be duplicated and usage on the Chromebook SSD will
> unnecessarily increase.
> Would it be reasonable to add a discard option when enabling the
> hydration process to discard data as we go on the source device?
> 2 implementations are possible:
> a- add a state to the hydration state machine to ensure a region is
> discarded before considering another region.
> b- a simpler implementation where the discard is sent asynchronously
> at the end of a region copy. It may not complete successfully (in case
> the device crashes during the hydration for instance), but will vastly
> reduce the amount of data left  in the source device at the end of the
> hydration.
> 
> I prefer b) as it is easier to implement, but a) is cleaner from a
> usage point of view.

In general, discards may not complete for any number of reasons. So
while a) gives you finer-grained potential for space being
deallocated, b) would likely suffice given that a device crash is
pretty unlikely (at least I would think).  And in the case of file
backed loopback devices, independent of dm-clone, you can just issue
discard(s) to all free space after a crash?

However you elect to do it, you'd do well to make it an optional
"discard_rw_src" (or some better name) feature that is configured when
you load the dm-clone target.

Mike



More information about the dm-devel mailing list