While TLC NAND technology allows to increase the storage capacity by storing 3-bits per cell, its access time is 2X ~ 3X slower compared to SLC. This is mainly because the extra cycles that each access requires, as well as the overhead of enhanced error correction. This issue of slow access, specifically of writing, has already derived people in the SSD industry several years ago, to set aside some portion of the storage as SLC NAND. As the NAND flash capacity is increasingly growing, this notion, known as *turbo-write* has swooped-in during the last year to be used in UFS devices. While in its final stages to become a UFS standard, I think it would be beneficial to discuss this topic during LSF/MM, so we'll be able to provide the community perspective beforehand. Among others, it is still not clear if this turbo-buffer is allocated as a single central buffer, or set aside per LUN, and how much say has the host in those decisions. Who decides, and on what terms, when the device can evacuate (flush) the data stored in its turbo-write buffer to some other, slower area of the device. What IO gets to be colored as "turbo"? is it decided in user land, designating a file or a node by an applicable stream ID or write-hint (see [1] and [2])? Or is it a specific request using command priority? Or looking at the page cache as a whole, and using the turbo-write buffer as a gear-shifting mechanism when cache levels are rising? We will be able to present initial results of those directions that we already explored, and will happily accepts some more ideas. [1] https://lwn.net/Articles/717755/ [2] https://lwn.net/Articles/726477/
