On Mon, Feb 6, 2023 at 3:35 PM Matias Bjørling <Matias.Bjorling@xxxxxxx> wrote: > > > Maybe it is one beginning for generic open-source userspace SSD FTL, which > > could be useful for people curious in SSD internal. I have google several times > > for such toolkit to see if it can be ported to UBLK easily. SSD simulator isn't > > great, which isn't disk and can't handle real data & workloads. With such > > project, SSD simulator could be less useful, IMO. > > > > Another possible avenue could be the FTL module that's part of SPDK. It might be worth checking out as well. It has been battletested for a couple of years and is used in production (https://www.youtube.com/watch?v=qeNBSjGq0dA). > > The module itself could be extracted from SPDK into its own, or SPDK's ublk extension could be used to instantiate it. In any case, I think it could provide a solid foundation for a host-side FTL implementation. Thanks for bringing SPDK's CSAL up, I think it's a great example of a well implemented host-ftl. It does require a fast caching device with persistence guarantees (like optane) though, not entirely unlike dm-zoned. It also lives in the spdk universe, which makes it a bit harder to work with than a standalone ftl. While a cache in front of the backing storage gives the ftl some time to organize writes in a device-friendly manner before flushing, it adds cost (write amplification or having to add a fast persistent cache device) I've seen that SPDK already has the required plumbing for UBLK: https://spdk.io/doc/ublk.html I don't know if IO can be routed to CSAL yet. That said, it would be great to support the CSAL use case in a common ftl. Not all workloads require a cache, so I think that caching should be optimal. Raiding and supporting multiple tenants from a combined pool of storage is super-nice. Cheers, Hans
