On 01/11/2017 05:07 AM, Damien Le Moal wrote: > > Matias, > > On 1/10/17 22:06, Matias Bjorling wrote: >> On 01/10/2017 05:24 AM, Theodore Ts'o wrote: >>> This may be an area where if we can create the right framework, and >>> fund some research work, we might be able to get some researchers and >>> their graduate students interested in doing some work in figuring out >>> what sort of divisions of responsibilities and hints back and forth >>> between the storage device and host have the most benefit. >>> >> >> That is a good idea. There is a couple of papers at FAST with >> Open-Channel SSDs this year. They look into the interface and various >> ways to reduce latency fluctuations. >> >> One thing I've heard a couple of times is the feature to move the GC >> read/write process into the firmware. Enabling the host to offload GC >> data movement, while the keeping the host in control. Would this be >> beneficial for SMR? > > Host-aware SMR drives already have GC internally implemented (for cases > when the host does not write sequentially). Host-managed drives do not. > As for moving an application specific GC code into the device, well, > code injection in the storage device is not for tomorrow, and likely not > ever. > > There are however other clever ways to reduce GC related host overhead > with basic commands. For SCSI, these may be WRITE SCATTERED, EXTENDED > COPY, and some others can greatly improve overhead over a simple > read+write loop. A better approach to GC offload may not be a "GC" > command, but something more generic for moving around LBAs internally > within the device. That is, if existing commands are not satisfactory. Hi Damien, You're right. I was thinking of something similar to scattered read/write to move data from one place to another. There is no sector-granularity mapping table maintained by the OCSSD, which leaves the logic up to the host. Let me know if you decide to kick of a standardized interface for code injection. Such an interface is long overdue. ;) -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
