Samsung t5 / t3 problem with ncq trim

Samsung t5 / t3 problem with ncq trim

[Sven Hugi]

Hello

I hope, that this is the correct mailinglist... if not, pls let me know...

So, it seams, that there is a problem with the samsung t5 and t3,
those ssds are just samsung 850 with an usb-c adapter.
I wrote a mail to linux-ide, but Damien Le Moal suggested to me to
write it to the maintainer of uas.c...
My idea was to patch this in the ata_device_blacklist in
libata-core.c, but since this seams not to be the solution, i have no
idea how to do it...
So, it would be nice, if someone how knows what he is doing could have
a look at it.

Sorry for my poor english.

I hope this helps somehow to fix the problem.

Best regards

Sven Hugi

Re: Samsung t5 / t3 problem with ncq trim

[Martin K. Petersen]

Sven,

> So, it seams, that there is a problem with the samsung t5 and t3,

What, specifically, is the problem?

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: Samsung t5 / t3 problem with ncq trim

[Sven Hugi]

Hello Martin

It seams, that those 2 ssds do not like ncq trim
In the mail i sent to linux-ide I included 4 lines of code for the
ata_device_blacklist in libata-core.c, but since Damien Le Moal
suggested to me to
write it to the maintainer of uas.c I didn't include those 4 lines...
(ht thinks, that i could be because of the usb-adapter on those ssds)
Those line where:

{ "Samsung Portable SSD T5",    NULL,   ATA_HORKAGE_NO_NCQ_TRIM |
                                        ATA_HORKAGE_ZERO_AFTER_TRIM, },
{ "Samsung Portable SSD T3",    NULL,   ATA_HORKAGE_NO_NCQ_TRIM |
                                        ATA_HORKAGE_ZERO_AFTER_TRIM, },

But because this seams not to work, i can just say, that those ssds
are suicidal, probably because of ncq trim.
I hope, that this helps you to understand, what the problem is...

Best regards

Sven Hugi

Am Mi., 19. Jan. 2022 um 04:20 Uhr schrieb Martin K. Petersen
<martin.petersen@oracle.com>:
>
>
> Sven,
>
> > So, it seams, that there is a problem with the samsung t5 and t3,
>
> What, specifically, is the problem?
>
> --
> Martin K. Petersen      Oracle Linux Engineering



-- 
Sven Hugi

github.com/ExtraTNT

Re: Samsung t5 / t3 problem with ncq trim

[Martin K. Petersen]

Sven,

> It seams, that those 2 ssds do not like ncq trim

Please be specific wrt. the type of error you are seeing.

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: Samsung t5 / t3 problem with ncq trim

[Sven Hugi]

Hello Martin

so, there was no error, only death and misery...
ok, storytime
I used a t5 for school (because we needed to use a t5, because the
school sold it for double the price)
So, my ssd got really slow over the time, we were not allowed to use a
other filesystem than ntfs, so i thought that it was simply because of
this.
But it go down to about 500 kbs. Had a talk with a teacher, he told
me, something like fuck the rules, reformate it to exfat, ntfs is just
shit...
So, it didn't do a lot. Initialy the problem was only while using
gnu/linux, but later also while using windows (school computer).
This went on a few weeks, till the vm's on the disk got corrupted, the
first 2 weeks or so was after runing them a few times, after that just
by copying them on the disk.
Speed was low af... So, i contacted the support, this was like: "we
are legally required to support you, but no"
So i got back to my teacher, he sended me a new disk. I got the disk,
tested the speed on my gaming pc (windows), that was good.
Got on my working machine, copyed the vm's to the disk and the speed
just droped... had a call with the teacher on 2am, we did some
research on this ssd and figured out, that the t5 (and also t3) are
just samsung 850 with an usb-c adapter.
The 850 had a problem with ncq trim, disks randomly died and got slow
af with linux.
So, i took a look at the ata drivers and found the
ata_device_blacklist in libata-core.c.
My idea was to just add those 2 ssds to it:
{ "Samsung Portable SSD T5",    NULL,   ATA_HORKAGE_NO_NCQ_TRIM |
                                        ATA_HORKAGE_ZERO_AFTER_TRIM, },
{ "Samsung Portable SSD T3",    NULL,   ATA_HORKAGE_NO_NCQ_TRIM |
                                        ATA_HORKAGE_ZERO_AFTER_TRIM, },
Sent a mail to linux-ide, Damien Le Moal respondet, that it's probably
the usb-c adapter causing the problem and that i should contact the
maintainer of uas.c...
And here we are...

So, that's the short version of the storry, i hope, that this helps...

Best regards

Sven Hugi

Am Mi., 19. Jan. 2022 um 17:31 Uhr schrieb Martin K. Petersen
<martin.petersen@oracle.com>:
>
>
> Sven,
>
> > It seams, that those 2 ssds do not like ncq trim
>
> Please be specific wrt. the type of error you are seeing.
>
> --
> Martin K. Petersen      Oracle Linux Engineering



-- 
Sven Hugi

github.com/ExtraTNT

Re: Samsung t5 / t3 problem with ncq trim

[Martin K. Petersen]

Sven,

> The 850 had a problem with ncq trim, disks randomly died and got slow
> af with linux.

The NCQ quirk does not apply in your case since the drive is attached to
Linux via UAS. The UAS-SATA bridge drive may or may not be using NCQ
when talking to the drive; we have no way of knowing or influencing that
decision, that's all internal to the drive. We only see what is
presented on its external USB interface.

I don't have a T5 so I don't know about that. But I do have a T3 and it
does not report LBPME which is the SCSI way of saying the drive supports
TRIM. So Linux isn't even going to attempt to TRIM the drive in this
configuration.

You are welcome to send the output of the following commands:

# sg_inq /dev/sdN

# sg_readcap -l /dev/sdN

# sg_vpd -p bl /dev/sdN

# sg_vpd -p lbpv /dev/sdN

for your T5 so we can see what it reports. But with respect to the
queued TRIM issue, there isn't really anything that can be done from the
Linux side since this is all internal to the device.

Had the mSATA drive been directly attached to a SATA controller and not
a UAS-to-SATA bridge things would have been different. The special
handling of the 850 in libata is meant to address the scenario where
Linux is talking to the SATA drive directly. In that configuration the
decision about whether to queue or not queue the DSM TRIM operation lies
with Linux.

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: Samsung t5 / t3 problem with ncq trim

[Sven Hugi]

Hello Martin

Thx, i will test that tomorow and send you the result.
Best case would be, that i got 2 bad SSDs and there is nothing to patch.
But 2 bad SSDs, in this case i should play in the lottery...

Anyways, we know that the t3 definitely does not have this issue...

Best regards

Sven Hugi

Am Mi., 19. Jan. 2022 um 23:38 Uhr schrieb Martin K. Petersen
<martin.petersen@oracle.com>:
>
>
> Sven,
>
> > The 850 had a problem with ncq trim, disks randomly died and got slow
> > af with linux.
>
> The NCQ quirk does not apply in your case since the drive is attached to
> Linux via UAS. The UAS-SATA bridge drive may or may not be using NCQ
> when talking to the drive; we have no way of knowing or influencing that
> decision, that's all internal to the drive. We only see what is
> presented on its external USB interface.
>
> I don't have a T5 so I don't know about that. But I do have a T3 and it
> does not report LBPME which is the SCSI way of saying the drive supports
> TRIM. So Linux isn't even going to attempt to TRIM the drive in this
> configuration.
>
> You are welcome to send the output of the following commands:
>
> # sg_inq /dev/sdN
>
> # sg_readcap -l /dev/sdN
>
> # sg_vpd -p bl /dev/sdN
>
> # sg_vpd -p lbpv /dev/sdN
>
> for your T5 so we can see what it reports. But with respect to the
> queued TRIM issue, there isn't really anything that can be done from the
> Linux side since this is all internal to the device.
>
> Had the mSATA drive been directly attached to a SATA controller and not
> a UAS-to-SATA bridge things would have been different. The special
> handling of the 850 in libata is meant to address the scenario where
> Linux is talking to the SATA drive directly. In that configuration the
> decision about whether to queue or not queue the DSM TRIM operation lies
> with Linux.
>
> --
> Martin K. Petersen      Oracle Linux Engineering



-- 
Sven Hugi

github.com/ExtraTNT

Re: Samsung t5 / t3 problem with ncq trim

[Sven Hugi]

so:

 -> sudo sg_inq sda
standard INQUIRY:
  PQual=0  Device_type=0  RMB=0  LU_CONG=0  version=0x06  [SPC-4]
  [AERC=0]  [TrmTsk=0]  NormACA=0  HiSUP=0  Resp_data_format=2
  SCCS=0  ACC=0  TPGS=0  3PC=0  Protect=0  [BQue=0]
  EncServ=0  MultiP=0  [MChngr=0]  [ACKREQQ=0]  Addr16=0
  [RelAdr=0]  WBus16=0  Sync=0  [Linked=0]  [TranDis=0]  CmdQue=1
  [SPI: Clocking=0x0  QAS=0  IUS=0]
    length=76 (0x4c)   Peripheral device type: disk
 Vendor identification: Samsung
 Product identification: Portable SSD T5
 Product revision level: 0
 Unit serial number: D3A3D7654321

 -> sudo sg_readcap -l sda
Read Capacity results:
   Protection: prot_en=0, p_type=0, p_i_exponent=0
   Logical block provisioning: lbpme=0, lbprz=0
   Last LBA=976773167 (0x3a38602f), Number of logical blocks=976773168
   Logical block length=512 bytes


   Logical blocks per physical block exponent=0
   Lowest aligned LBA=0
Hence:
   Device size: 500107862016 bytes, 476940.0 MiB, 500.11 GB

 -> sudo sg_vpd -p bl sda
Block limits VPD page (SBC):
  Write same non-zero (WSNZ): 0
  Maximum compare and write length: 0 blocks [Command not implemented]
  Optimal transfer length granularity: 1 blocks
  Maximum transfer length: 65535 blocks
  Optimal transfer length: 65535 blocks
  Maximum prefetch transfer length: 65535 blocks
  Maximum unmap LBA count: 4194240
  Maximum unmap block descriptor count: 1
  Optimal unmap granularity: 1 blocks
  Unmap granularity alignment valid: false
  Unmap granularity alignment: 0 [invalid]
  Maximum write same length: 0 blocks [not reported]
  Maximum atomic transfer length: 0 blocks [not reported]
  Atomic alignment: 0 [unaligned atomic writes permitted]
  Atomic transfer length granularity: 0 [no granularity requirement
  Maximum atomic transfer length with atomic boundary: 0 blocks [not reported]
  Maximum atomic boundary size: 0 blocks [can only write atomic 1 block]

 -> sudo sg_vpd -p lbpv sda
Logical block provisioning VPD page (SBC):
  Unmap command supported (LBPU): 1
  Write same (16) with unmap bit supported (LBPWS): 0
  Write same (10) with unmap bit supported (LBPWS10): 0
  Logical block provisioning read zeros (LBPRZ): 0
  Anchored LBAs supported (ANC_SUP): 0
  Threshold exponent: 0 [threshold sets not supported]
  Descriptor present (DP): 0
  Minimum percentage: 0 [not reported]
  Provisioning type: 0 (not known or fully provisioned)
  Threshold percentage: 0 [percentages not supported]

lbpme=0...
so, i guess it's not because of trim...

Am Do., 20. Jan. 2022 um 00:02 Uhr schrieb Sven Hugi <hugi.sven@gmail.com>:
>
> Hello Martin
>
> Thx, i will test that tomorow and send you the result.
> Best case would be, that i got 2 bad SSDs and there is nothing to patch.
> But 2 bad SSDs, in this case i should play in the lottery...
>
> Anyways, we know that the t3 definitely does not have this issue...
>
> Best regards
>
> Sven Hugi
>
> Am Mi., 19. Jan. 2022 um 23:38 Uhr schrieb Martin K. Petersen
> <martin.petersen@oracle.com>:
> >
> >
> > Sven,
> >
> > > The 850 had a problem with ncq trim, disks randomly died and got slow
> > > af with linux.
> >
> > The NCQ quirk does not apply in your case since the drive is attached to
> > Linux via UAS. The UAS-SATA bridge drive may or may not be using NCQ
> > when talking to the drive; we have no way of knowing or influencing that
> > decision, that's all internal to the drive. We only see what is
> > presented on its external USB interface.
> >
> > I don't have a T5 so I don't know about that. But I do have a T3 and it
> > does not report LBPME which is the SCSI way of saying the drive supports
> > TRIM. So Linux isn't even going to attempt to TRIM the drive in this
> > configuration.
> >
> > You are welcome to send the output of the following commands:
> >
> > # sg_inq /dev/sdN
> >
> > # sg_readcap -l /dev/sdN
> >
> > # sg_vpd -p bl /dev/sdN
> >
> > # sg_vpd -p lbpv /dev/sdN
> >
> > for your T5 so we can see what it reports. But with respect to the
> > queued TRIM issue, there isn't really anything that can be done from the
> > Linux side since this is all internal to the device.
> >
> > Had the mSATA drive been directly attached to a SATA controller and not
> > a UAS-to-SATA bridge things would have been different. The special
> > handling of the 850 in libata is meant to address the scenario where
> > Linux is talking to the SATA drive directly. In that configuration the
> > decision about whether to queue or not queue the DSM TRIM operation lies
> > with Linux.
> >
> > --
> > Martin K. Petersen      Oracle Linux Engineering
>
>
>
> --
> Sven Hugi
>
> github.com/ExtraTNT



-- 
Sven Hugi

github.com/ExtraTNT

Re: Samsung t5 / t3 problem with ncq trim

[Martin K. Petersen]

Sven,

>  -> sudo sg_readcap -l sda
> Read Capacity results:
>    Protection: prot_en=0, p_type=0, p_i_exponent=0
>    Logical block provisioning: lbpme=0, lbprz=0
>    Last LBA=976773167 (0x3a38602f), Number of logical blocks=976773168
>    Logical block length=512 bytes

> lbpme=0...
> so, i guess it's not because of trim...

Correct, Linux wouldn't be sending trims to that drive.

-- 
Martin K. Petersen	Oracle Linux Engineering

Re: Samsung t5 / t3 problem with ncq trim

[Sven Hugi]

Hello Martin

I just don't get it, why i get the same problems, as reported with the
850 on the t5...
I mean it's the 2nd t5 i used and i used it on 4 different devices (+
on the school computer).
The t5 i currently have, runs really slow on linux and more or less
without problem on windows, the one i had before behaved really
similar, till it started to corrupt vm's and then also slow down on
windows...
Do you have an idea, what that could be?, or does it sound like i just
got 2 defective disks?

Best regards

Sven Hugi

Am Fr., 21. Jan. 2022 um 03:15 Uhr schrieb Martin K. Petersen
<martin.petersen@oracle.com>:
>
>
> Sven,
>
> >  -> sudo sg_readcap -l sda
> > Read Capacity results:
> >    Protection: prot_en=0, p_type=0, p_i_exponent=0
> >    Logical block provisioning: lbpme=0, lbprz=0
> >    Last LBA=976773167 (0x3a38602f), Number of logical blocks=976773168
> >    Logical block length=512 bytes
>
> > lbpme=0...
> > so, i guess it's not because of trim...
>
> Correct, Linux wouldn't be sending trims to that drive.
>
> --
> Martin K. Petersen      Oracle Linux Engineering



-- 
Sven Hugi

github.com/ExtraTNT

Re: Samsung t5 / t3 problem with ncq trim

[Damien Le Moal]

On 1/22/22 02:23, Sven Hugi wrote:
> Hello Martin
> 
> I just don't get it, why i get the same problems, as reported with the
> 850 on the t5...
> I mean it's the 2nd t5 i used and i used it on 4 different devices (+
> on the school computer).
> The t5 i currently have, runs really slow on linux and more or less
> without problem on windows, the one i had before behaved really
> similar, till it started to corrupt vm's and then also slow down on
> windows...
> Do you have an idea, what that could be?, or does it sound like i just
> got 2 defective disks?

It may be a drive firmware bug. Note that this article:

https://www.tomshardware.com/reviews/samsung-t5-portable-ssd,5163-3.html

mentions a similar performance problems with older versions of the T5
that do not have TRIM support. It is mentioned that newer versions have
TRIM support though.

So it may be worthwhile to check if a firmware update is available for
your drive.


> 
> Best regards
> 
> Sven Hugi
> 
> Am Fr., 21. Jan. 2022 um 03:15 Uhr schrieb Martin K. Petersen
> <martin.petersen@oracle.com>:
>>
>>
>> Sven,
>>
>>>  -> sudo sg_readcap -l sda
>>> Read Capacity results:
>>>    Protection: prot_en=0, p_type=0, p_i_exponent=0
>>>    Logical block provisioning: lbpme=0, lbprz=0
>>>    Last LBA=976773167 (0x3a38602f), Number of logical blocks=976773168
>>>    Logical block length=512 bytes
>>
>>> lbpme=0...
>>> so, i guess it's not because of trim...
>>
>> Correct, Linux wouldn't be sending trims to that drive.
>>
>> --
>> Martin K. Petersen      Oracle Linux Engineering
> 
> 
> 


-- 
Damien Le Moal
Western Digital Research

Re: Samsung t5 / t3 problem with ncq trim

[Sven Hugi]

Thx for the tip.
I was finally able to test it.
The disk seems to work now correctly.

So, i guess i slap the person, who told me, that the disks have new
firmware on it... xD

Am Sa., 22. Jan. 2022 um 02:05 Uhr schrieb Damien Le Moal
<damien.lemoal@opensource.wdc.com>:
>
> On 1/22/22 02:23, Sven Hugi wrote:
> > Hello Martin
> >
> > I just don't get it, why i get the same problems, as reported with the
> > 850 on the t5...
> > I mean it's the 2nd t5 i used and i used it on 4 different devices (+
> > on the school computer).
> > The t5 i currently have, runs really slow on linux and more or less
> > without problem on windows, the one i had before behaved really
> > similar, till it started to corrupt vm's and then also slow down on
> > windows...
> > Do you have an idea, what that could be?, or does it sound like i just
> > got 2 defective disks?
>
> It may be a drive firmware bug. Note that this article:
>
> https://www.tomshardware.com/reviews/samsung-t5-portable-ssd,5163-3.html
>
> mentions a similar performance problems with older versions of the T5
> that do not have TRIM support. It is mentioned that newer versions have
> TRIM support though.
>
> So it may be worthwhile to check if a firmware update is available for
> your drive.
>
>
> >
> > Best regards
> >
> > Sven Hugi
> >
> > Am Fr., 21. Jan. 2022 um 03:15 Uhr schrieb Martin K. Petersen
> > <martin.petersen@oracle.com>:
> >>
> >>
> >> Sven,
> >>
> >>>  -> sudo sg_readcap -l sda
> >>> Read Capacity results:
> >>>    Protection: prot_en=0, p_type=0, p_i_exponent=0
> >>>    Logical block provisioning: lbpme=0, lbprz=0
> >>>    Last LBA=976773167 (0x3a38602f), Number of logical blocks=976773168
> >>>    Logical block length=512 bytes
> >>
> >>> lbpme=0...
> >>> so, i guess it's not because of trim...
> >>
> >> Correct, Linux wouldn't be sending trims to that drive.
> >>
> >> --
> >> Martin K. Petersen      Oracle Linux Engineering
> >
> >
> >
>
>
> --
> Damien Le Moal
> Western Digital Research



-- 
Sven Hugi

github.com/ExtraTNT