On Tuesday 12 June 2012, Ted Ts'o wrote: > 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? I don't think that can be derived from the definition of the context. Instead, the important part is that we separate the data with predictable lifetime from data with unpredictable lifetime. If we happen to be writing both a linear file on the one hand (or multiple such files) and at the same time updating a database, any reasonable implementation would be able to benefit from the fact that the linear data is now in a different erase block from the random-access data. The database file is still screwed like it is without context support, but it no longer makes the linear access worse. > 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.... Right. The danger here is that the context support was described in the standard first, while none of the devices seem to even be smart enough to make use of the information we put in there. Once operating systems start putting some data in there, at least some manufacturers will start making use of that data to optimize the accesses, but it's very unlikely that they will tell us exactly what they are doing. Having code in ext4 that uses the contexts will at least make it more likely that the firmware optimizations are based on ext4 measurements rather than some other file system or operating system. >From talking with the emmc device vendors, I can tell you that ext4 is very high on the list of file systems to optimize for, because they all target Android products. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
