I was about to buy a Samsung 850 Pro SSD, but then I came across this:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/ata/libata-core.c?id=9a9324d3969678d44b330e1230ad2c8ae67acf81
Apparently there was an issue with data corruption, causing TRIM on these drives to be blacklisted by the kernel.
Has this issue been resolved in the Xenial kernel, or is TRIM still blacklisted for those drives?
I know how to enable TRIM on a drive which supports it, but the question is: will it work on the 850 Pro, because if it is still broken on that drive under Linux, I won’t bother spending money on it (especially since it is one of the more expensive consumer SSD models).
As far as I’m concerned, any SSD without proper trim support under Linux is a no-go.
Hah - guess which drive I bought yesterday!
i’ve got an 256GB 850 PRO.
I’ve done some quick googling, and tried the test on this page
it seems to fail - I don’t get a bunch of zeroes at the end. 
EDIT:
it’s a pretty old test - don’t know how definitive it may be - so to test the test I ran it on my laptop which has an intel SSD
the test failed again!
CONCLUSION:
crap test, i still don’t know if my SSD is being trimmed…
Did you mount the drive with the “discard” option for automatic trim?
Otherwise that might have been the reason. The liked page also states that if you do not get all zeroes, it does not necessarily mean trim is broken on some drives. Only the reverse is reliable: all zeroes = trim is definitely working.
Does it work if you run
/sbin/fstrim --all
after removing the temp file to force a trim run?
I also found a couple more things:
i edited my post just before you posted - did you see my edit before posting?
i would like to know if a definitive test exists to test my SSD
about the discard option - do you mean in fstab?
Yes, discard in fstab.
ok - give me a few minutes and i’ll give it a go.
luckily it’s a new drive, new installed, no data to lose if things go horribly wrong!
If it does work, I’d also be interested to know if there is any noticeable performance impact, since it should do synchronous instead of queued TRIM as the blacklisting is still enabled.
OK, with the discard option in fstab, i do get all zeroes - which means my drive will get regular trims.
why isn’t ‘discard’ included by default - risk of data corruption?
not sure how to easily measure any performance impact - any ideas?
How about copying a large file to the SSD immediately after “rm + sync” (which should trigger trim)?
Also, according to https://askubuntu.com/questions/18903/how-to-enable-trim/19480#19480 Ubuntu 14.04 and later by default do scheduled TRIM via the /etc/cron.weekly/fstrim job - “discard” in fstab is deprecated.
so, i don’t really understand all this fully - what’s the conclusion?
was this drive a good buy - or have i over-purchased?
if so, would it be better to use this drive for windows instead, and use another non black-listed drive for linux?
Ok, I found a good explaination on Wikipedia (https://en.wikipedia.org/wiki/Trim_(computing)):
The original version of the TRIM command has been defined as a non-queued command by the T13 subcommittee,
and consequently can incur massive execution penalty if used
carelessly, e.g., if sent after each filesystem delete command. The
non-queued nature of the command requires the driver to first wait for
all outstanding commands to be finished, issue the TRIM command, then
resume normal commands. TRIM can take a lot of time to complete,
depending on the firmware in the SSD, and may even trigger a garbage collection cycle.[citation needed]
This penalty can be minimized in solutions that periodically do a
batched TRIM, rather than trimming upon every file deletion, by
scheduling such batch jobs for times when system utilization is minimal.
This TRIM shortcoming has been overcome in Serial ATA revision 3.1 with the introduction of the Queued TRIM Command.
This boils down to: synchronous TRIM is bad for performance if you run it on every delete (via “discard”). Hence the move to a cron job that does a full trim on a weekly basis.
The Samsung 850 Pro does support trim, as seen in your test, but only synchronous due to the blacklist still in effect.
So if you do not use “discard” in fstab and just rely on the fstrim cron job, you should be fine.
And yes, it looks like I’m going to get the 850 Pro now after all.
thanks for that explanation - much clearer now.
looks like it’s time to edit fstab again to discard the discard…
An on going problem from what I see on launchpad. A firmware problem.
https://bugs.launchpad.net/ubuntu/+source/fstrim/+bug/1449005
Older Samsung drives got a firmware update that introduced queued TRIM, (which the 850 Pro had from the start), and that triggered the issue.
Windows from what I read apparently does not use queued TRIM, yet, thus was unaffected.
But in any case, it should be resolved with blacklist plus the fix I mentioned earlier.
I have been using a 512 GB 850 Pro for three days now, and sure enough, dmesg mentions queued trim being disabled for the partitions on that drive, as expected.
No issues so far - it is extremely fast and fstrim works just fine.
Btw. I discovered that the small Mushkin Chronos SSD I already had in my system does not support queued TRIM at all because it uses the older SATA 3.0 spec instead of 3.1. Never have had any performance issues with that drive, either.
I’m no expert in these things. I have a spare Samsung 850 EVO 250GB SSD that I was thinking of using on another Ubuntu Mate install. Is it okay to do a manual trim by using this command?
sudo fstrim -v /
My main Linux Mate install is on a Kingston Now SSD (128GB) and also a Linux Mint system with the identical Kingston drive, that has been running great for over a year.
BTW, my newish Core i5 latest generation system is running perfectly on Ubuntu Mate 16.04.
Yes, that should work fine.
There is a weekly cron job which does a fstrim on all supported partitions, but you may want to change the hour in /etc/crontab if your PC isn’t usually running between 6 and 7 a.m. .