On Sun, Dec 25, 2022 at 10:27:49AM -0500, Mouse wrote:
> >> 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
On Sun, Dec 25, 2022 at 11:10:44AM -0500, Mouse wrote:
> >> I find it far more plausible that I'm doing something wrong.
> > Or maybe the drive just doesn't obey the spec?
>
> That's possible, I suppose. But it's a brand new Kingston SSD
I've used quite a few Kingston SSDs in BSD systems over
>> I find it far more plausible that I'm doing something wrong.
> Or maybe the drive just doesn't obey the spec?
That's possible, I suppose. But it's a brand new Kingston SSD, which I
would expect would support TRIM. And it self-identifies as supporting
TRIM.
The packaging promises free
On Sun, Dec 25, 2022 at 10:27:49AM -0500, Mouse wrote:
> I find it far more plausible that I'm doing something wrong.
Or maybe the drive just doesn't obey the spec?
I've got a disk here that, when sent a SECERASE, writes 0x00 to the first 1 Gb
of the media and leaves the rest unchanged. That
>> 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
> 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.
[dholland]
> 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.
[RVP]
> OK, I've now actually looked at what the spec[1] says instead of
> relying on my faulty recall of stuff I read on
On Mon, Dec 12, 2022 at 11:53:56PM +1100, matthew green wrote:
> maybe port that tool back, it's also supposed to match the
> linux command of the same name. it's not in netbsd-9, but
> last i tried, the interfaces the -current tool uses are
> available in -9 kernels.
The trim/discard
> are you trying to trim a really large section at once? i think
> that's what i see:
>> [ - root] 3> date; ./trim /dev/rwd1d 4 2; date
That means "first six bytes contain 4, LE; second two bytes contain 2,
LE". I thought that in turn meant "2 sectors at offset 4". Apparently
it actually
On Sat, 10 Dec 2022, Mouse wrote:
OK, so any requests >4K will have to be packaged into further range
requests [...]
This isn't right. Bytes 7 & 8 of a TRIM range request form a
counter. So, a counter of 1 = (1 x max_dsm_blocks); 2 = (2 x
max_dsm_blocks) up to 0x counts.
So is
are you trying to trim a really large section at once? i
think that's what i see:
> [ - root] 3> date; ./trim /dev/rwd1d 4 2; date
at least in my experience, the problem is that most devices
take a while to handle a TRIM request, longer than the 30s
timeout typically used.
this is why
>> OK, so any requests >4K will have to be packaged into further range
>> requests [...]
> This isn't right. Bytes 7 & 8 of a TRIM range request form a
> counter. So, a counter of 1 = (1 x max_dsm_blocks); 2 = (2 x
> max_dsm_blocks) up to 0x counts.
So is max_dsm_blocks misnamed, or is it
>> I tried trimming 8 at 0. Still the same syndrome: TRIM timeout,
>> flush timeout, device timeout reading [...]
> You may have to set the AT_LBA48 flag (not sure if this is present on
> 5.2)
It is not. 5.2 has an ATA_LBA48 flag, going with the flags field of
struct ata_bio, but no LBA48 flag
On Fri, 9 Dec 2022, RVP wrote:
OK, so any requests >4K will have to be packaged into further range
requests [...]
This isn't right. Bytes 7 & 8 of a TRIM range request form a counter. So,
a counter of 1 = (1 x max_dsm_blocks); 2 = (2 x max_dsm_blocks) up to
0x counts. And you can have 64
On Fri, 9 Dec 2022, Mouse wrote:
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.
>> 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
On Thu, 8 Dec 2022, Mouse wrote:
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
On Thu, 8 Dec 2022, Mouse wrote:
I will have to dig into that more. It does seem to be waiting, in that
the call does not return until the thirty seconds specified in the
timeout field have elapsed. (It then takes about another 30s before
printing the cache-flush timeout message and returning
On Thu, Dec 08, 2022 at 11:44:59PM -0500, Mouse wrote:
> Since the data on the device is still there afterwards, I don't think
> [...]
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.
What
[Replying to two messages at once here, both from the same person]
[First message]
>> printf("TRIM %s: calling exec\n",device_xname(wd->sc_dev));
>> rv = wd->atabus->ata_exec_command(wd->drvp,);
>> printf("TRIM %s: returned %d\n",device_xname(wd->sc_dev),rv);
>>
On Wed, 7 Dec 2022, Mouse wrote:
case ATAIOCTRIM:
{ unsigned char rq[512];
struct ata_command cmd;
[...]
printf("TRIM %s: calling exec\n",device_xname(wd->sc_dev));
rv = wd->atabus->ata_exec_command(wd->drvp,);
On Wed, 7 Dec 2022, Mouse wrote:
printf("TRIM %s: calling exec\n",device_xname(wd->sc_dev));
rv = wd->atabus->ata_exec_command(wd->drvp,);
printf("TRIM %s: returned %d\n",device_xname(wd->sc_dev),rv);
return(0);
ata_exec_command() will
>> [...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
>>> I'm trying to understand TRIM, such as is used on SSDs. [...]
>> [...]
> It could perhaps be that the area you're trying to trim is too small,
> or badly aligned?
Entirely possible. What are the restrictions? Are they
device-specific, or generic? (While wedging seems like a rather broken
On Thu 08 Dec 2022 at 10:23:19 -0500, Mouse wrote:
> I wrote
>
> > I'm trying to understand TRIM, such as is used on SSDs. [...]
>
> I forgot to ask: does anyone know whether TRIM is known to work? It
It could perhaps be that the area you're trying to trim is too small, or
badly aligned?
I wrote
> I'm trying to understand TRIM, such as is used on SSDs. [...]
I forgot to ask: does anyone know whether TRIM is known to work? It
occurs to me that I don't actually know whether the code I'm trying to
backport works. The code looks more or less identical in current,
according to
I'm trying to understand TRIM, such as is used on SSDs.
As a first step towards this, I'm trying to do a rudimentary backport
to a 5.2 derivative I'm using - nothing teaches a thing like
implementing it. I found wd_trim() in 9.2's wd.c and had a stab at
integrating a form of it into my kernel.
27 matches
Mail list logo
