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 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 Ma
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
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 th
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
>> 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 technic
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 cle
>> 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 prev
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 w
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/de
> 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.
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 th
12 matches
Mail list logo