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. Gwendal. -- dm-devel mailing list dm-devel@redhat.com https://listman.redhat.com/mailman/listinfo/dm-devel
