thanks, Matias, I am going to look out for dm-zap! On Thu, Jan 21, 2021 at 12:14 PM Matias Bjørling <mb@xxxxxxxxxxx> wrote: > > On 21/01/2021 20.49, Heiner Litz wrote: > > there are a couple more, but again I would understand if those are > > deemed not important enough to keep it. > > > > device emulation of (non-ZNS) SSD block device > > That'll soon be available. We will be open-sourcing a new device mapper > (dm-zap), which implements an indirection layer that enables ZNS SSDs to > be exposed as a conventional block device. > > > die control: yes endurance groups would help but I am not aware of any > > vendor supporting it > It is out there. Although, is this still important in 2021? OCSSD was > made back in the days where media program/erase suspend wasn't commonly > available and SSD controller were more simple. With today's media and > SSD controllers, it is hard to compete without leaving media throughput > on the table. If needed, splitting a drive into a few partitions should > be sufficient for many many types of workloads. > > finer-grained control: 1000's of open blocks vs. a handful of > > concurrently open zones > > It is dependent on the implementation - ZNS SSDs also supports 1000's of > open zones. > > Wrt to available OCSSD hardware - there isn't, to my knowledge, proper > implementations available, where media reliability is taken into account. > > Generally for the OCSSD hardware implementations, their UBER is > extremely low, and as such RAID or similar schemes must be implemented > on the host. pblk does not implement this, so at best, one should not > store data if one wants to get it back at some point. It also makes for > an unfair SSD comparison, as there is much more to an SSD than what > OCSSD + pblk implements. At worst, it'll lead to false understanding of > the challenges of making SSDs, and at best, work can be used as the > foundation for doing an actual SSD implementation. > > > OOB area: helpful for L2P recovery > > It is known as LBA metadata in NVMe. It is commonly available in many of > today's SSD. > > I understand your point that there is a lot of flexibility, but my > counter point is that there isn't anything in OCSSD, that is not > implementable or commonly available using today's NVMe concepts. > Furthermore, the known OCSSD research platforms can easily be updated to > expose the OCSSD characteristics through standardized NVMe concepts. > That would probably make for a good research paper. > >
