Comment 4 for bug 1332720

Revision history for this message
Peter Curtis (pdcurtis) wrote :

Although this is an old thread there are some additional twists which I would like to add as this is currently where a search for an associated problem brings one and it affects @pinumbernumber and any changes to the release notes @miketwebster makes.

There currently seems to be a problem with a number of the more common SSD drives including most of the Samsung 8xx range when used with Linux kernels later than 3.12 and before 4.0.5 which is to do with the new queued TRIM command allegedly not being implemented correctly in the drives. See https://bugs.launchpad.net/ubuntu/+source/fstrim/+bug/1449005 and https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1338706. There is a back-port of the work around which blacklists ‘Queued TRIM’ on the problem drives but as far as I can see it does not cover the default kernels used in 17 17.1 and 17.2 as it was applied at 3.13.0-57.95, 3.16.0-43.58 and 3.19.0-22.22

The result is that there will be an almost inevitable and serious data loss on Samsung SSDs with this problem as TRIM is automatically called by default by a cron job in Mint every week. As far as I can tell it will affect all new 8xx SSDs and earlier ones if the firmware is updated. The Samsung 840 Pro and Evo both have a firmware update which exposes the problem but also improves there performance considerably so many people will unsuspectingly apply it and then kill their system at some random time in the following week.

For information only Linux has implemented the new queued TRIM so Windows systems and Mac OSX are not affected at this time so there is no urgency for Samsung to fix it on new production or provide a firmware update and there approach to Linux is ambiguous.

Mint has chosen the conservative "Don't fix unless broken" approach to kernel updates so the essential kernel update will have to be applied manually. I have not yet investigated when the cron job runs the first time relative to the initial install. If it is immediate the only way round it is to modify /etc/cron.weekly/fstrim from the liveUSB or LiveDVD before the install is run the first time, update the kernel and change it back.

As SSDs are now a favourite update and the Samsung range is a likely candidate I wonder if a suitable kernel update should be made a recommended (level 2) update in 17, 17.1 and 17.2. @clem is aware from a posting I made in the last monthly news and I understand that 17.3 should have an appropriate kernel.

I have a personal interest as I had put a Samsung 850 Evo on order before I found out about the potential problem and then quite by chance! I will add any further information I get when my new machine arrives .

@miketwebster Should I also put in a new bug report as well as my input here?