On Mon, May 11 2009, Jörn Engel wrote: > On Mon, 11 May 2009 04:37:54 -0400, Theodore Tso wrote: > > > > Well, no one has actually implemented the low-level TRIM support yet; > > Iirc dwmw2 did so for some of the FTL drivers. More a curiosity than a > useful device, though. > > > Well, no, Matthew's changes didn't do any of that, I suspect because > > most SSD's, including X25-M, are expected to have a granularity size > > of 1 block. It's the crazy people in the SCSI standards world who've > > been pushing for granlarity sizes in the 1-4 megabyte range; as I > > understand things, the granularity issue was not going to be a problem > > for the ATA TRIM command. > > I am not sure about this part. So far Intel has been the only party to > release any information about their dark-grey box. All other boxes are > still solid black. And until I'm told otherwise I'd consider them to be > stupid devices that use erase block size as trim granularity. > > Given the total lack of information, your guess is as good as mine, > though. > > > As far as thinking that the proposal is ludicrous --- what precisely > > did you find ludicrous about it? > > Mainly the idea that discard requests should act as barriers and instead > of fixing that, you propose a lot of complexity to work around it. But the command is effectively a barrier at the device level anyway, since you need to drain the hardware queue before issuing. > > The only problem with SSD's is the people who designed the ATA TRIM > > command requires us to completely drian the I/O queue before issuing > > it. Because of this incompetence, we need to be a bit more careful > > about how we issue them. > > And this bit that I wasn't aware of. Such a requirement in the standard > is a trainwreck indeed. Precisely, but that's how basically anything works with SATA NCQ, only read/write dma commands may be queued. Anything else requires an idle drive before issue. -- Jens Axboe -- 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
