NCQ TRIM Gets Some Improvements With Linux 4.2

[phoronix]

Phoronix: NCQ TRIM Gets Some Improvements With Linux 4.2

The libata updates for the Linux 4.2 kernel may be of interest this time around for solid-state drive owners thanks to some NCQ TRIM improvements...

http://www.phoronix.com/scan.php?pag...ibata-NCQ-TRIM

[Solid State Brain]

In an ideal world, SSDs reporting NCQ TRIM support shouldn't be having issues with it as it extends what regular TRIM does. This is a very much needed improvement, but it's kind of ridiculous that kernel developers had to resort to make it an option due to widespread data loss issues at a device firmware level.

[Guest]

In an ideal world, SSDs reporting NCQ TRIM support shouldn't be having issues with it as it extends what regular TRIM does. This is a very much needed improvement, but it's kind of ridiculous that kernel developers had to resort to make it an option due to widespread data loss issues at a device firmware level.

I don't see how this helps anything but trim performance, been a while since I've read sata 3.1 spec but afaik this is basically implementation of queued trim so you don't have to 'suffer' trough disadvantages of '-o discard' which are lower IOPS and higher latency. Unless I've misread something, this is only gonna help people with sata 3.1 compatible hardware anyway (and there aren't a lot of them just yet).
Queued TRIM doesn't make online-trim any easier, in fact those drives are gonna need even more complicated firmware logic (imho).

[atomt]

I don't see how this helps anything but trim performance, been a while since I've read sata 3.1 spec but afaik this is basically implementation of queued trim so you don't have to 'suffer' trough disadvantages of '-o discard' which are lower IOPS and higher latency. Unless I've misread something, this is only gonna help people with sata 3.1 compatible hardware anyway (and there aren't a lot of them just yet).
Queued TRIM doesn't make online-trim any easier, in fact those drives are gonna need even more complicated firmware logic (imho).

The major problem with the old TRIM is that you have to pause all other I/O (drain the command queue) to run it. This obviously causes major performance problems not just for the TRIM command, but anything else happening around the same time. With queued TRIM its just another entry in the queue, which can also be run in parallell with other commands in the queue if the controller is up for it.

For client workloads that is usually not a huge deal though.

[Solid State Brain]

I don't see how this helps anything but trim performance, been a while since I've read sata 3.1 spec but afaik this is basically implementation of queued trim so you don't have to 'suffer' trough disadvantages of '-o discard' which are lower IOPS and higher latency. Unless I've misread something, this is only gonna help people with sata 3.1 compatible hardware anyway (and there aren't a lot of them just yet).
Queued TRIM doesn't make online-trim any easier, in fact those drives are gonna need even more complicated firmware logic (imho).

I meant that efforts toward the change/workaround described in this news wouldn't have been necessary (thus, welcome or "needed") if only the implementation of queued TRIM of so many SSD wasn't that buggy. This makes me question why SSD manufacturers enabled it in the first place.

Previously, NCQ TRIM would be automatically used by the kernel if the discard flag was enabled and the underlying hardware advertised support for it.

[GreatEmerald]

I don't see much use for this. TRIM is only useful every once in a blue moon, pretty much only once your SSD fills up. One TRIM per filesystem creation is often enough, and doing it too often is just not a good idea for modern SSDs.

[gigaplex]

I don't see much use for this. TRIM is only useful every once in a blue moon, pretty much only once your SSD fills up. One TRIM per filesystem creation is often enough, and doing it too often is just not a good idea for modern SSDs.

That's just not true. It's better for the SSD longevity if you use TRIM, otherwise the garbage collection routines will increase write amplification as it will maintain the unused stale data.

[gentoofu]

    /* devices that don't properly handle queued TRIM commands */
{ "Micron_M500_*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |ATA_HORKAGE_ZERO_AFTER_TRIM, },
{ "Crucial_CT*M500*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |ATA_HORKAGE_ZERO_AFTER_TRIM, },
{ "Micron_M5[15]0*", "MU01", ATA_HORKAGE_NO_NCQ_TRIM |ATA_HORKAGE_ZERO_AFTER_TRIM, },
{ "Crucial_CT*M550*", "MU01", ATA_HORKAGE_NO_NCQ_TRIM |ATA_HORKAGE_ZERO_AFTER_TRIM, },
{ "Crucial_CT*MX100*", "MU01", ATA_HORKAGE_NO_NCQ_TRIM |ATA_HORKAGE_ZERO_AFTER_TRIM, },
{ "Samsung SSD 8*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |ATA_HORKAGE_ZERO_AFTER_TRIM, },

These popular drives that have been selling like hotcakes can now has NCQ TRIM?

[gigaplex]

    /* devices that don't properly handle queued TRIM commands */
{ "Micron_M500_*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |ATA_HORKAGE_ZERO_AFTER_TRIM, },
{ "Crucial_CT*M500*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |ATA_HORKAGE_ZERO_AFTER_TRIM, },
{ "Micron_M5[15]0*", "MU01", ATA_HORKAGE_NO_NCQ_TRIM |ATA_HORKAGE_ZERO_AFTER_TRIM, },
{ "Crucial_CT*M550*", "MU01", ATA_HORKAGE_NO_NCQ_TRIM |ATA_HORKAGE_ZERO_AFTER_TRIM, },
{ "Crucial_CT*MX100*", "MU01", ATA_HORKAGE_NO_NCQ_TRIM |ATA_HORKAGE_ZERO_AFTER_TRIM, },
{ "Samsung SSD 8*", NULL, ATA_HORKAGE_NO_NCQ_TRIM |ATA_HORKAGE_ZERO_AFTER_TRIM, },

These popular drives that have been selling like hotcakes can now has NCQ TRIM?

Unlikely. I got the impression that these kernel improvements are just fine grained controls to turn legacy TRIM back on while leaving queued TRIM disabled.

[Ropid]

I don't see how this helps anything but trim performance, been a while since I've read sata 3.1 spec but afaik this is basically implementation of queued trim so you don't have to 'suffer' trough disadvantages of '-o discard' which are lower IOPS and higher latency. Unless I've misread something, this is only gonna help people with sata 3.1 compatible hardware anyway (and there aren't a lot of them just yet).
Queued TRIM doesn't make online-trim any easier, in fact those drives are gonna need even more complicated firmware logic (imho).

$ sudo smartctl -a /dev/sda | grep SATA\ Version
SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)

$ sudo smartctl -a /dev/sdb | grep SATA\ Version
SATA Version is:  SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)

$ sudo smartctl -a /dev/sdc | grep SATA\ Version
SATA Version is:  SATA 3.0, 6.0 Gb/s (current: 3.0 Gb/s)

I bought both the /dev/sda drive and the motherboard at the end of 2012.