On Fri, Sep 16, 2022 at 1:01 PM Bart Van Assche <bvanassche@xxxxxxx> wrote: > > On 9/16/22 11:48, Sarthak Kukreti wrote: > > Yes. On ChromiumOS, we regularly deal with storage devices that don't > > support WRITE_ZEROES or that need to have it disabled, via a quirk, > > due to a bug in the vendor's implementation. Using WRITE_ZEROES for > > allocation makes the allocation path quite slow for such devices (not > > to mention the effect on storage lifetime), so having a separate > > provisioning construct is very appealing. Even for devices that do > > support an efficient WRITE_ZEROES implementation but don't support > > logical provisioning per-se, I suppose that the allocation path might > > be a bit faster (the device driver's request queue would report > > 'max_provision_sectors'=0 and the request would be short circuited > > there) although I haven't benchmarked the difference. > > Some background information about why ChromiumOS uses thin provisioning > instead of a single filesystem across the entire storage device would be > welcome. Although UFS devices support thin provisioning I am not aware > of any use cases in Android that would benefit from UFS thin > provisioning support. > Sure (and I'd be happy to put this in the cover letter, if you prefer; I didn't include it initially, since it seemed orthogonal to the discussion of the patchset)! On ChromiumOS, the primary driving force for using thin provisioning is to have flexible, segmented block storage, both per-user and for applications/virtual machines with several useful properties, for example: block-level encrypted user storage, snapshot based A-B updates for verified content, on-demand partitioning for short-lived use cases. Several of the other planned use-cases (like verified content retention over powerwash) require flexible on-demand block storage that is decoupled from the primary filesystem(s) so that we can have cryptographic erase for the user partitions and keep the on-demand, dm-verity backed executables intact. Best Sarthak > Thanks, > > Bart. -- dm-devel mailing list dm-devel@xxxxxxxxxx https://listman.redhat.com/mailman/listinfo/dm-devel
