Add quirks for Samsung 750 EVO SSD

[sbruno]

Summary

Samsung 750 EVO SSD is missed in our quirk dayabase. It is 4K device, reported as 512 bytes one.

[mav]

Is there reason why for ATA "Samsung" is lower-case, while for SATL it is upper-case? Does some SATL implementation convert strings to upper case? I don't remember about such fact.

[lev]

In D9478#195912, @mav wrote:

Is there reason why for ATA "Samsung" is lower-case, while for SATL it is upper-case? Does some SATL implementation convert strings to upper case?

It's my copy'n'paste error. 750 EVO uses "Samsung" according to boot message.

[lev]

750 reports "Samsung", not "SAMSUNG".

[mav]

This comment was removed by mav.

[mav]

I have no objections if this information is proven.

[lev]

In D9478#195922, @mav wrote:

I have no objections if this information is proven.

I'm not sure how to check "TRIM with NCQ" for sure. fio (benchmarks/fio) could run "trim" task with I/O depth 4 with "posixaio" driver in "direct" mode without problems (with 4K-sized 4K-aligned) requests . Is it enough?

[mav]

In D9478#195926, @lev wrote:

In D9478#195922, @mav wrote:

I have no objections if this information is proven.

I'm not sure how to check "TRIM with NCQ" for sure. fio (benchmarks/fio) could run "trim" task with I/O depth 4 with "posixaio" driver in "direct" mode without problems (with 4K-sized 4K-aligned) requests . Is it enough?

IIRC broken "TRIM with NCQ" was quite nontrivial to find out. It happened only on very specific complicated workloads. So I believe that it is more of fixed blacklist of early broken drives, then something that should be updated. I'd assume that anything other those specific drives either don't support the NCQ TRIM or does support it (either of those is fine), unless third case is diagnosed. I'd not mentioned it without need here, unless you know it for sure from some reliable sources.

[imp]

In D9478#195931, @mav wrote:

In D9478#195926, @lev wrote:

In D9478#195922, @mav wrote:

I have no objections if this information is proven.

I'm not sure how to check "TRIM with NCQ" for sure. fio (benchmarks/fio) could run "trim" task with I/O depth 4 with "posixaio" driver in "direct" mode without problems (with 4K-sized 4K-aligned) requests . Is it enough?

IIRC broken "TRIM with NCQ" was quite nontrivial to find out. It happened only on very specific complicated workloads. So I believe that it is more of fixed blacklist of early broken drives, then something that should be updated. I'd assume that anything other those specific drives either don't support the NCQ TRIM or does support it (either of those is fine), unless third case is diagnosed. I'd not mentioned it without need here, unless you know it for sure from some reliable sources.

Well, Broken TRIM with NCQ is easy to find out. Enable it and copy trees of files and delete trees of files. Reboot. You'll know right away if NCQ TRIM is broken. The drives with a broken TRIM with NCQ corrupt data rather profusely broken.

To check to see if TRIM with NCQ is working, you can run FIO with lots of threads and look at gstat -d to see if the queue depth is larger than 1.

[j-nitrology.com]

Assuming this has been used locally with NCQ TRIM for a while or it's been confirmed with imp's suggestion, we should get this in.