On 3/2/12 3:00 PM, Theodore Ts'o wrote: > I spent an hour talking to architecture guy from a major flash > manufacturer, who makes everything from SSD's to SD cards to eMMC > devices, and he said a few things that were interesting. > > One is that he would actually be very happy if we send lots of extra > trim commands; in particular, he would actually *like* us to send trims > at unlink/commit time, *and* trims periodically via FITRIM. The reason > for that is because that way, if the disk is busy, it would be OK if he > dropped the TRIM on the floor, knowing that he would get another bite at > the apple later on. But, if the disk has time to process the trim, he > he would be able to use that information as quickly as possible. Is that within spec? > One of the other things we talked about was it would be really nice if > we could send TRIM commands at journal checkpoint time, and perhaps send > checkpoints more aggressively (although the requirement to send a > SYNCHORNIZE CACHE command may make this be too expensive, unless we have > ways of reliably knowing when the disk is idle, since unlike the > enterprise server case, when ext4 is used in a mobile device, the fs > accesses patterns tend to have more gaps where this sort of maintenance > can take place). > > We also talked about ways that we might right some application notes so > that handset OEM's understood how to use mke2fs parameters to optimize > their file systems for different types of flash systems, and perhaps > ways that the eMMC spec could be enhanced so that key parameters such as > erase block size, flash page size, and translation table granularity > could be passed back to the block layer, and made available to file > system and mkfs. Now that would be nice. Could some of this just be piggybacked on the existing preferred_io_size-type geometry interfaces? -Eric > Anyway, going back to TRIM, I suspect that efforts to optimize out TRIM > requests may not make as much sense once we have devices with are SATA > 3.1 complaint, when we will have a queuable TRIM command. Also, > presumably SATA 3.1 compliance devices are less likely to have > disastrous firmware bugs that make TRIM such a performance dog, and in > fact they may be devices that would very much like as much TRIM > information as we are willing to send to them. > > Regards, > > - Ted > -- > To unsubscribe from this list: send the line "unsubscribe linux-ext4" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
