On Mon, Mar 27 2023 at 4:24P -0400, Gwendal Grignou <gwendal@xxxxxxxxxxxx> 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 -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
