tech-kern archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: ATA TRIM?
>> Okay, that now seems unlikely. I tried to TRIM 32M at zero.
(Actually, 16M - 32K blocks is 16M.)
> What is the value of `max_dsm_blocks' that your drive reports?
> Unfortunately, atactl(8) doesn't show this currently.
I added that - and the version numbers - to my printf.
atap_ata_major is 2040, 0x7f8.
atap_ata_minor is 283, 0x11b.
max_dsm_blocks is 8.
I tried trimming 8 at 0. Still the same syndrome: TRIM timeout, cache
flush timeout, device timeout reading - and I just now noticed that the
last timeout is a timeout reading wd*0*. This leads me to suspect that
it's the host hardware, not the drive, that's falling over here
(presumably trying to load dd to read wd1 with). Is that plausible?
I did another test. I tried to trim 8 at 0, but, first, I started a
loop that reads successive blocks of wd0, the OS's disk, one per
second, printing timestamps as it goes.
wd0 access locks up during the TRIM attempt. One read got through
between that and the cache flush; it locked up again during that. It
then came back. But when I tried to read wd1 it locked up again during
that.
Dunno what all this means....
/~\ 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
Home |
Main Index |
Thread Index |
Old Index