In the past, Samsung's SATA SSDs couldn't execute queued TRIM commands in a Linux environment. The company fixed the issue in the 860 series. The 860 Pro is also the first consumer SSD advertised for use in a NAS environment.

My scheduler is running trim at 20:00 and the first error happend at 20:00 - did a test now and trim is working - so no idea, what error this is...

And now you need to handle SATA 3.0 which requires 6 Gbit/s when connecting a SSD.

And since the power needed increases with the frequency of the signal, they can't use very high voltages for the signals - with high voltages (that better handles external noise) the driver circuit feeding the cable signals will start to consume huge amounts of power. So the signals has a swing of 1.5 V.

In the past, Samsung's SATA SSDs couldn't execute queued TRIM commands in a Linux environment. The company fixed the issue in the 860 series. The 860 Pro is also the first consumer SSD advertised for use in a NAS environment

If Samsung have such issue before, why don't simple think it still have such problem even they said fix on 860 series. ( In fact just know that issue )

Share this post

Link to post

I did a little more searching and came across this post. The bottom line is this issue resolved itself after running TRIM twice. So, I rain trim twice. It appears that the issue is not presenting in the system log.