Page MenuHomeFreeBSD

Add quirks for Samsung 750 EVO SSD
ClosedPublic

Authored by sbruno on Feb 7 2017, 4:39 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Dec 5, 12:29 AM
Unknown Object (File)
Nov 12 2024, 9:48 AM
Unknown Object (File)
Nov 10 2024, 4:49 AM
Unknown Object (File)
Nov 8 2024, 9:02 PM
Unknown Object (File)
Nov 8 2024, 8:52 PM
Unknown Object (File)
Nov 8 2024, 8:48 PM
Unknown Object (File)
Nov 8 2024, 8:41 PM
Unknown Object (File)
Nov 8 2024, 8:06 PM
Subscribers

Details

Summary

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

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Not Applicable
Unit
Tests Not Applicable

Event Timeline

lev retitled this revision from to Add quirks for Samsung 750 EVO SSD.
lev updated this object.
lev edited the test plan for this revision. (Show Details)
lev added reviewers: sbruno, mav.
lev set the repository for this revision to rS FreeBSD src repository - subversion.

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.

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 edited edge metadata.
lev removed rS FreeBSD src repository - subversion as the repository for this revision.

750 reports "Samsung", not "SAMSUNG".

This comment was removed by mav.
mav edited edge metadata.

I have no objections if this information is proven.

This revision is now accepted and ready to land.Feb 7 2017, 6:06 PM
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?

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.

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.

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.

sbruno edited reviewers, added: lev; removed: sbruno.
This revision was automatically updated to reflect the committed changes.