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)
Mon, Dec 23, 10:53 AM
Unknown Object (File)
Sat, Dec 21, 1:48 AM
Unknown Object (File)
Fri, Dec 20, 11:07 PM
Unknown Object (File)
Thu, Dec 12, 12:03 PM
Unknown Object (File)
Mon, Dec 9, 11:34 AM
Unknown Object (File)
Nov 19 2024, 6:28 PM
Unknown Object (File)
Nov 9 2024, 6:03 PM
Unknown Object (File)
Oct 29 2024, 3:25 AM
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 Skipped
Unit
Tests Skipped
Build Status
Buildable 7257

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.