Re: ATA TRIM?
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 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. I believe the drive is allowed to discard the request, in which case you'll read the old data. I expect at that point the block is not "trimmed" but ... that's a detail. I know at least some drives will ignore single-sector trims. -- David A. Holland dholl...@netbsd.org
Re: KSYMS_CLOSEST
On Sun, Dec 25, 2022 at 17:41:10 +0100, Anders Magnusson wrote:
> Den 2022-12-25 kl. 17:25, skrev Valery Ushakov:
> > On Sun, Dec 25, 2022 at 15:42:47 +0100, Anders Magnusson wrote:
> >
> > > Den 2022-12-25 kl. 13:43, skrev Valery Ushakov:
> > > > On Sun, Dec 25, 2022 at 09:20:49 +0100, Anders Magnusson wrote:
> > > >
> > > > > IIRC it was to match the ddb "sift" command.
> > > > I'm not sure I get how it might be used for sifting - a kind of "next"
> > > > for external iteration? Since we never got around to do that do we
> > > > still want to keep it, or shall we deprecate/delete it?
> > >
> > > Ah! I had to look at the code - no, it has nothing to do with sift.
> > > I think it is implicit when asking for a name these days; it is used
> > > to get nearest lower address address in debug output. (like
> > > tstile+0x18 )
> >
> > Right, right, but I wonder what could it possibly mean then, when the
> > flag is not specified - as opposed to the example above. I.e. if
> > KSYMS_CLOSEST is foo+0x10, what KSYMS_EXTERN (i.e. no specific flags)
> > could be, other than foo+0x10, for the same address? I mean,
> > technically, netbsd + 0xcaffe42 would also be a correct reply in that
> > case :)
>
> :-) If you are not specifying KSYMS_EXACT, you may not get the exact
> address, yes. That is true :-)
>
> > Also, checking the very first versions of ksyms code I don't see
> > KSYMS_CLOSEST ever actually handled (it's defined and specified in the
> > ddb strategy defines, but never tested in ksyms). May be I missed
> > some later short-lived incarnation.
> >
> > The existing call sites that supply the flag look like cargo-cult^W^W
> > common sense ("looks like you might need to specify that flag to get
> > foo+0x10, well, *shrug*, won't hurt").
> I assume that might be the case, yes.
> The ksyms code comes from another system for which I wrote it a long time
> ago, where the meaning may have had a significance (do not remember).
> But feel free to clean this up. (IMHO KSYMS_EXACT should be the default,
> requiring KSYMS_CLOSEST to be defined if that is requested).
But KSYMS_EXACT has different meaning. It means to look for exactly
"foo" (foo+0) and fail otherwise.
if ((f & KSYMS_EXACT) && (v != es->st_value))
return ENOENT;
-uwe
Re: KSYMS_CLOSEST
Den 2022-12-25 kl. 17:25, skrev Valery Ushakov:
On Sun, Dec 25, 2022 at 15:42:47 +0100, Anders Magnusson wrote:
Den 2022-12-25 kl. 13:43, skrev Valery Ushakov:
On Sun, Dec 25, 2022 at 09:20:49 +0100, Anders Magnusson wrote:
IIRC it was to match the ddb "sift" command.
I'm not sure I get how it might be used for sifting - a kind of "next"
for external iteration? Since we never got around to do that do we
still want to keep it, or shall we deprecate/delete it?
Ah! I had to look at the code - no, it has nothing to do with sift.
I think it is implicit when asking for a name these days; it is used
to get nearest lower address address in debug output. (like
tstile+0x18 )
Right, right, but I wonder what could it possibly mean then, when the
flag is not specified - as opposed to the example above. I.e. if
KSYMS_CLOSEST is foo+0x10, what KSYMS_EXTERN (i.e. no specific flags)
could be, other than foo+0x10, for the same address? I mean,
technically, netbsd + 0xcaffe42 would also be a correct reply in that
case :)
:-) If you are not specifying KSYMS_EXACT, you may not get the exact
address, yes. That is true :-)
Also, checking the very first versions of ksyms code I don't see
KSYMS_CLOSEST ever actually handled (it's defined and specified in the
ddb strategy defines, but never tested in ksyms). May be I missed
some later short-lived incarnation.
The existing call sites that supply the flag look like cargo-cult^W^W
common sense ("looks like you might need to specify that flag to get
foo+0x10, well, *shrug*, won't hurt").
I assume that might be the case, yes.
The ksyms code comes from another system for which I wrote it a long
time ago, where the meaning may have had a significance (do not remember).
But feel free to clean this up. (IMHO KSYMS_EXACT should be the
default, requiring KSYMS_CLOSEST to be defined if that is requested).
-- Ragge
Re: ATA 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 the last ten years or so, and whilst they work they have all shown some odd behaviours compared to other brands. Specifically, after a couple of years of use they suddenly become very slow to _read_, I had one that was literally reading at about 2 or 3 Mb/sec compared to ~140 Mb/sec previously in the same system. A secerase has always fixed this issue every time I've encountered it. BUT, the secerase leaves the device bricked for about 60 minutes or sometimes longer. I.E. it blocks the SATA bus and most machines just hang at the BIOS for about 45 seconds until they time out. Power cycling the bricked device seemingly does nothing to help, you just have to wait until it eventually reverts to normal behaviour. We have at least five Kingston SSDs here that have all exhibited this behaviour. I've never seen it with any other SSD, and have used plenty of Crucial, Corsair, and others. > The packaging promises free technical support. I suppose I should try > to chase down a contact (the packaging gives no hint whom to contact > for that promised support) and ask. At worst I'll be told nothing > useful. That would be interesting.
Re: KSYMS_CLOSEST
On Sun, Dec 25, 2022 at 15:42:47 +0100, Anders Magnusson wrote:
> Den 2022-12-25 kl. 13:43, skrev Valery Ushakov:
> > On Sun, Dec 25, 2022 at 09:20:49 +0100, Anders Magnusson wrote:
> >
> > > IIRC it was to match the ddb "sift" command.
> > I'm not sure I get how it might be used for sifting - a kind of "next"
> > for external iteration? Since we never got around to do that do we
> > still want to keep it, or shall we deprecate/delete it?
>
> Ah! I had to look at the code - no, it has nothing to do with sift.
> I think it is implicit when asking for a name these days; it is used
> to get nearest lower address address in debug output. (like
> tstile+0x18 )
Right, right, but I wonder what could it possibly mean then, when the
flag is not specified - as opposed to the example above. I.e. if
KSYMS_CLOSEST is foo+0x10, what KSYMS_EXTERN (i.e. no specific flags)
could be, other than foo+0x10, for the same address? I mean,
technically, netbsd + 0xcaffe42 would also be a correct reply in that
case :)
Also, checking the very first versions of ksyms code I don't see
KSYMS_CLOSEST ever actually handled (it's defined and specified in the
ddb strategy defines, but never tested in ksyms). May be I missed
some later short-lived incarnation.
The existing call sites that supply the flag look like cargo-cult^W^W
common sense ("looks like you might need to specify that flag to get
foo+0x10, well, *shrug*, won't hurt").
-uwe
Re: ATA TRIM?
>> 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 technical support. I suppose I should try to chase down a contact (the packaging gives no hint whom to contact for that promised support) and ask. At worst I'll be told nothing useful. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: ATA TRIM?
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 clearly violates the spec.
Re: ATA TRIM?
>> 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 HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: KSYMS_CLOSEST
Den 2022-12-25 kl. 13:43, skrev Valery Ushakov: On Sun, Dec 25, 2022 at 09:20:49 +0100, Anders Magnusson wrote: IIRC it was to match the ddb "sift" command. I'm not sure I get how it might be used for sifting - a kind of "next" for external iteration? Since we never got around to do that do we still want to keep it, or shall we deprecate/delete it? Ah! I had to look at the code - no, it has nothing to do with sift. I think it is implicit when asking for a name these days; it is used to get nearest lower address address in debug output. (like tstile+0x18 ) Yes, I think it can be removed, but the DDB code must be cleaned up as well since it seem that it uses it in a bunch of places. -- R Den 2022-12-25 kl. 01:01, skrev Valery Ushakov: KSYMS_CLOSEST flag is documented as "Nearest lower match". However as far as I can tell nothing in ksyms code ever pays attention to this flag and it's not clear to me what meaning one can ascribe to the set of flags that doesn't have KSYMS_CLOSEST set. Ragge, do you remember what did you have in mind for it when you introduced it back in 2003? I think we should g/c it. -uwe -uwe
Re: KSYMS_CLOSEST
On Sun, Dec 25, 2022 at 09:20:49 +0100, Anders Magnusson wrote: > IIRC it was to match the ddb "sift" command. I'm not sure I get how it might be used for sifting - a kind of "next" for external iteration? Since we never got around to do that do we still want to keep it, or shall we deprecate/delete it? > Den 2022-12-25 kl. 01:01, skrev Valery Ushakov: > > KSYMS_CLOSEST flag is documented as "Nearest lower match". However as > > far as I can tell nothing in ksyms code ever pays attention to this > > flag and it's not clear to me what meaning one can ascribe to the set > > of flags that doesn't have KSYMS_CLOSEST set. > > > > Ragge, do you remember what did you have in mind for it when you > > introduced it back in 2003? > > > > I think we should g/c it. > > > > -uwe -uwe
Re: ATA TRIM?
> 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.
Re: KSYMS_CLOSEST
IIRC it was to match the ddb "sift" command. Den 2022-12-25 kl. 01:01, skrev Valery Ushakov: KSYMS_CLOSEST flag is documented as "Nearest lower match". However as far as I can tell nothing in ksyms code ever pays attention to this flag and it's not clear to me what meaning one can ascribe to the set of flags that doesn't have KSYMS_CLOSEST set. Ragge, do you remember what did you have in mind for it when you introduced it back in 2003? I think we should g/c it. -uwe
