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@xxxxxxxxxx>: > > > 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
