On Tue, Jun 12, 2012 at 02:55:50PM +0000, Arnd Bergmann wrote: > > As I said, it's not a technical limitation, but a logical conclusion > from trying to use the context ID for something useful. The only > reason to use context ID in the first place is to reduce the amount > of garbage collection in the device (improving performance and expected > life of the device), so any context ID annotations we make should be > directed at giving useful information to the device to actually do that. ... and a big part of that is knowing what is the downside if we give incorrect information to the device. And what are the exact implications of what it means to group a set of blocks into a "context". If it is fundamentally a promise that blocks in a context will be overwritten or trimmed at the same time then is it counterproductive to group blocks for overwrite-in-place database where the lifetimes of the block are extremely different? Is that giving "wrong" information going to significantly increase the write amplification factor? It may be that the standard doesn't actually answer these questions and even worse, SSD manufactures may be stupidly trying to keep this stuff as a "trade securet" --- but we do need to know in order to optimize performance on real hardware.... - Ted -- 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
