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. > Logical head depop rears its head again... But yes, I think it's more sensible to have I/O functions which help GC (like UNMAP) instead of influencing the GC itself. Anyway. Given the length of this thread I guess this is a worthy topic for LSF. Cheers, Hannes -- Dr. Hannes Reinecke Teamlead Storage & Networking hare@xxxxxxx +49 911 74053 688 SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: F. Imendörffer, J. Smithard, J. Guild, D. Upmanyu, G. Norton HRB 21284 (AG Nürnberg) -- To unsubscribe from this list: send the line "unsubscribe linux-block" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
