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
