On 2019/12/17 22:05, Enrico Weigelt, metux IT consult wrote: > On 17.12.19 01:26, Damien Le Moal wrote: > > Hi, > >> On the SSD front, NVMe Zoned Namespace standard is still a draft and >> being worked on be the NVMe committee and no devices are available on >> the market yet. > > anybody here who can tell why this could be useful ? To reduce device costs thanks to less flash over provisioning needed (leading to higher usable capacities), simpler device firmware FTL (leading to lower DRAM needs, so lower power and less heat) and higher predictability of IO latencies. Yes, there is the sequential write constraint (that's the "no free lunch" part of the picture), but many workloads can accommodate this constraint (any video streaming application, sensor logging, etc...) > Can erase blocks made be so enourmously huge and is there really a huge > gain in doing so, which makes any practical difference ? Making the erase block enormous would likely lead to enormous zone sizes, which is generally not desired as that becomes very costly if the application/user needs to do GC on the zones. A balance is generally reached here between HW media needs and usability. > Oh, BTW, since the write semantics seem so similar, why not treating > them similar to raw flashes ? This is the OpenChannel SSD model. This exists and is supported by Linux (lightnvm). This model is however more complex due to the plethora of parameters that the host can/needs to control. The zone model is much simpler and its application to NVMe with Zoned Namespace fits very well into the block IO stack work that was done for SMR since kernel 4.10. Another reason for choosing ZNS over OCSSD is that device vendors can actually give guarantees for devices sold as the device firmware retains control over the the flash cells health management, which is much less the case for OCSSD (the device health depends much more on what the user is doing). Best regards. -- Damien Le Moal Western Digital Research
