Re: [PATCH] lightnvm: fix memory leak when submit fails

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.





[Index of Archives]     [Linux RAID]     [Linux SCSI]     [Linux ATA RAID]     [IDE]     [Linux Wireless]     [Linux Kernel]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Device Mapper]

  Powered by Linux