Re: [PATCH RFC v1 00/01] dm-lightnvm introduction

[Richard Weinberger]

On Fri, Mar 21, 2014 at 7:32 AM, Matias Bjørling <m@xxxxxxxxxxx> wrote:
> Hi,
>
> Users that have custom firmware SSDs, may choose to expose their flash directly.
> This allows the host to control logical to physical address mappings, garbage
> collection strategy, wear-leveling, and so on.
>
> This is beneficial when you either want to strip the cost of a costly controller
> or want detailed control over an SSD. Such as implementing key-value stores,
> object-stored, atomic I/Os, etc.
>
> LightNVM implements the host-side core. It supports two modes. Users that
> doesn't have hardware available and want to emulate an SSD, and users with a
> physical SSD, that has a LightNVM compatible firmware.
>
> The behavior of the core can be exposed through the various components that make
> up an FTL. Thus, it is not single implementation, but instead possible to
> mix the best algorithms for the user-space application workloads.
>
> Currently, LightNVM implements a page-based FTL, cost-based GC and simple
> wear-leveling. Additionally, it allows simulation of flash timings when hardware
> isn't available. There's work on getting it to the OpenSSD platform with a
> custom firmware and getting it stable for broad use.
>
> There is still much work to do. I'm looking for feedback on the approach, dm
> integration, and more. Any feedback is greatly appreciated.
>
> A presentation was given at the recent Non-Volatile Memory Workshop (NVMW)
> workshop. Slides are available at: http://bjorling.me/NVMW2014-LightNVM.pdf
>
> Major todo's:
>  * Patch has TODO and FIXME in places that needs to be cleaned.
>  * LightNVM compatible firmware for the OpenSSD platform and integration.
>  * Performance regressions during GC.
>  * Durability during power failure.

This sounds very interesting!

Is there also a way to expose the flash directly as MTD device?
I'm thinking of UBI. Maybe both projects can benefit from each others.

-- 
Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/