>> [...TRIM...]
> It could perhaps be that the area you're trying to trim is too small,
> or badly aligned?
Okay, that now seems unlikely. I tried to TRIM 32M at zero. (Much
more than that seems implausible, since the request has only 16 bits of
size, so the maximum representible size is 65535 blocks, or a smidgen
under 64M. And zero certainlky ought to be aligned.)
The behaviour is basically the same. Except for the details, like the
argument area, it looks the same:
[ - root] 3> trim /dev/rwd1d 0 32768
TRIM wd1: arg 00 00 00 00 00 00 00 80
TRIM wd1: calling exec
piixide1:0:1: lost interrupt
type: ata tc_bcount: 512 tc_skip: 0
TRIM wd1: returned 1
ATAIOCTRIM workd
wd1: wd_flushcache: status=128<TIMEOU>
[ - root] 4>
[ - root] 4> dd if=/dev/rwd1d of=/dev/null count=64
piixide1:0:1: wait timed out
wd1d: device timeout reading fsbn 0 (wd1 bn 0; cn 0 tn 0 sn 0), retrying
wd1: soft error (corrected)
64+0 records in
64+0 records out
32768 bytes transferred in 0.008 secs (4096000 bytes/sec)
[ - root] 5>
That is, the request starts and nothing happens until the 30-second
timeout expires, at which point it reports "lost interrupt" and says it
worked. It then reports another timeout on cache flush. Attempting to
read gives _another_ timeout, from which it recovers and then works.
And, as before, reading the beginning of the drive indicates that the
first hundred sectors, at least, still retain the test data I wrote to
them before I started all this.
Hm, the device packaging promises free technical support. As cynical
as I may be about vendor support, I suppose I really ought to call them
up and see if they can put me in touch with someone who actually knows
how TRIM works. I don't really have anything to lose except some time.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
