Re: ATA TRIM?

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> According to that PDF, dholland is wrong.
> I fail to see a behaviour that would be allowed due to dholland@'s
> definition, but not according to the one you cited, nor the other way
> round.

A read returning the pre-TRIM contents.  Two of the options
specifically state "independent of the previously written value"; the
third is simply zero, which is also independent of the previously
written value.  dholland wrote

> The state of the data after TRIM is unspecified; you might read the
> old data, you might read zeros or ones, you might (I think) even read
> something else.

and, as I read that PDF, "you might read the old data" is specifically
disallowed.  You may read zeros or ones, or something else, but the
only way you'll read the old data is if the old data matches what the
drive's algorithm happens to return for those sectors (for example, if
the drive returns zeros but zeros were what you had written).

It is theoretically possible that the data I wrote happens to match
what the drive returns for trimmed sectors.  Given the data, I find
that extremely unlikely.  (I may try again with different data, just in
case, but I still don't like the way the command is timing out.  I find
it far more plausible that I'm doing something wrong.)

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B