On Fri, 2009-01-23 at 15:40 -0500, Ric Wheeler wrote: > Greg Freemyer wrote: > > Just to make sure I understand, with the proposed trim updates to the > > ATA spec (T13/e08137r2 draft), a SSD can have two kinds of data. > > > > Reliable and unreliable. Where unreliable can return zeros, ones, old > > data, random made up data, old data slightly adulterated, etc.. > > > > And there is no way for the kernel to distinguish if the particular > > data it is getting from the SSD is of the reliable or unreliable type? > > > > For the unreliable data, if the determistic bit is set in the identify > > block, then the kernel can be assured of reading the same unreliable > > data repeatedly, but still it has no way of knowing the data it is > > reading was ever even written to the SSD in the first place. > > > > That just seems unacceptable. > > > > Greg > > > Hi Greg, > > I sat in on a similar discussion in T10 . With luck, the T13 people have > the same high level design: > > (1) following a write to sector X, any subsequent read of X will return > that data > (2) once you DISCARD/UNMAP sector X, the device can return any state > (stale data, all 1's, all 0's) on the next read of that sector, but must > continue to return that data on following reads until the sector is > rewritten Actually, the latest draft: http://www.t10.org/cgi-bin/ac.pl?t=d&f=08-356r5.pdf extends this behaviour: If the array has read capacity(16) TPRZ bit set then the return for an unmapped block is always zero. If TPRZ isn't set, it's undefined but consistent. I think TPRZ is there to address security concerns. James -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
