Slashdot Mirror

← Back to Stories (view on slashdot.org)

Samsung Finds, Fixes Bug In Linux Trim Code

Posted by timothy on from the way-it-should-work dept.

New submitter Mokki writes: After many complaints that Samsung SSDs corrupted data when used with Linux, Samsung found out that the bug was in the Linux kernel and submitted a patch to fix it. It turns out that kernels without the final fix can corrupt data if the system is using linux md raid with raid0 or raid10 and issues trim/discard commands (either fstrim or by the filesystem itself). The vendor of the drive did not matter and the previous blacklisting of Samsung drives for broken queued trim support can be most likely lifted after further tests. According to this post the bug has been around for a long time.

22 of 184 comments (clear)

  1. awkward! by Anonymous Coward · · Score: 4, Insightful

    Well, that's gotta be embarrassing for everyone bashing Samsung over this. I remember reading some rather strong opinions about who was at fault.

    1. Re:awkward! by Anonymous Coward · · Score: 5, Insightful

      The firmware bug of Samsung drives, a very severe one actually, was confirmed by Samsung. The RAID 0 issue is a totally different one, hardly affecting anyone.

      So yes, the severe issue was a bug on Samsung side, thile the very rare RAID 0 bug is Linux kernel one.

    2. Re:awkward! by GigaplexNZ · · Score: 5, Informative

      I've read the articles. There are two separate bugs here. One, Samsung drives advertise support for queued TRIM even though it's not properly supported, causing corruption. Two, the kernel had a TRIM bug that affected serial TRIM with mdadm RAID, which is the kernel bug Samsung found and fixed. The queued TRIM bug still exists in the Samsung firmware.

  2. Bravo by Virtucon · · Score: 4, Interesting

    Nice to see vendors working together to improve Linux.

    --
    Harrison's Postulate - "For every action there is an equal and opposite criticism"
    1. Re:Bravo by gstoddart · · Score: 4, Insightful

      After many complaints that Samsung SSDs corrupted data when used with Linux

      There was definitely some self-interest there.

      Samsung can't have people saying their SSDs corrupt data when it's not them doing it.

      --
      Lost at C:>. Found at C.
    2. Re:Bravo by DarkOx · · Score: 5, Interesting

      Sure there was self interest. Still I think they deserve a lot of credit here. Rather than the typical "Its not my code" response from a developer who is sure the problem is elsewhere (rightly or wrongly) they actually found and fixed the problem. That is good behavior!

      --
      Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
    3. Re:Bravo by Anonymous Coward · · Score: 4, Insightful

      Of course, this is only possible when the "other person's" code is Free Software. If this had been a problem in Windows/OSX that Microsoft/Apple was refusing to fix, there's little Samsung could have done about it.

    4. Re: Bravo by bill_mcgonigle · · Score: 4, Interesting

      Yeah, the outcome is great. I just wonder why they waited more than a year to look into it. Maybe this will set a good example for the industry that with a little bit of effort you can take care of your customers and sell more product.

      If this were the 80's and a hard drive vendor had more than two reports of data loss under, say VMS, there would have been engineers on a plane to DEC by morning to get it solved by the coming weekend.

      Now we have thousands of users with reports and millions of units sold, and a wealthy vendor, and it's all crickets, leaving some kernel hackers to half-ass a blacklist. It's not like this is BeOS - there are millions of servers running in the target market. I don't mean to absolve the bad troubleshooting by kernel devs, but want to know what drove the apathy at Samsung (and other vendors behaving poorly). It's obviously not profit motive.

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
    5. Re: Bravo by bill_mcgonigle · · Score: 5, Informative

      I take some of that back. It seems the real credit for digging in goes to these guys. Samsung came in a month ago after they were provided a test suite and then gets credit for finding the kernel code path that caused the problem. An Oracle engineer provided a more-correct patch.

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
  3. Crying wolf by Sponge+Bath · · Score: 5, Informative

    When Apple updated OS X to allow TRIM on non-Apple supplied SSDs, forums were flooded with people claiming you should never use Samsung because they were fundamentally broken with regards to TRIM. Their "proof" was that corruption happened on Linux and they would not be swayed by the thought that maybe the problem was with Linux.

    1. Re:Crying wolf by beernutz · · Score: 4, Insightful

      The point however is that in a closed source system, Samsung could not have found and fixed the bug themselves.

      --
      (stolen from DaBum) I am dyslexia of borg - your ass will be laminated.
    2. Re:Crying wolf by kaiser423 · · Score: 5, Informative

      What makes you think that? Samsung is one signature away (PIA -- Proprietary Information Agreement) from viewing the vendor's source code and advising them. It's pretty damn routine and uncontroversial. I don't understand why people think that just because something is not open source that no one outside of the company ever, ever, under any circumstances can see a hunk of the code. Just sign a PIA and over the code in a secure manner, or give them remote VPN access to the test box. Pretty damn simple and routine.

    3. Re:Crying wolf by GigaplexNZ · · Score: 4, Informative

      That really depends on whether OS X uses serial or queued TRIM. The Samsung drives work fine with serial TRIM, but are still broken with queued TRIM. The bug that Algolia reported and Samsung fixed in the kernel was a serial TRIM issue in the Linux kernel with RAID, which is unrelated to the queued TRIM firmware issues.

  4. Just another case.... by darkain · · Score: 4, Insightful

    This is just another case of "Not My Problem" syndrome that too many techs get into. They think their code/tools/systems/whatever must be perfect, and other's are the ones fucking up. Samsung drives went on a blacklist for issuing the commands to them due to this bug? "WALP, LINUX IS PERFECT, MUST BE THE HARDWARE GUYS, even though their devices perform perfectly on other OSes" - and instead now we're left with a bug in Linux that corrupts data until the patch can make its way through the distro channels and pushed out to end users.

    1. Re:Just another case.... by 0123456 · · Score: 4, Interesting

      Devices working perfectly in other OSes is no indicator that the device is no at fault. Witness the vast amount of crap laptop hardware, whose disastrous ACPI implementations only worked because their Windows drivers were chock-full of workarounds.

      Back when I was writing Windows drivers for plugin cards, there were certain motherboards that we'd detect and switch the motherboard bus to the slowest possible speed, because the chipset was a heap of junk that didn't work properly at higher speeds. Anyone who said 'but it works on Windows!' clearly had no idea that it only worked because we'd intentionally turned off most of the features.

    2. Re:Just another case.... by nojayuk · · Score: 4, Interesting

      We did workarounds on the ATA bus spec for known hardware bugs in older VIA chipsets. These were silicon bugs, not chipset firmware so they couldn't be fixed afterwards with patches and there were millions of these boards out there. Declaring our devices (CD-ROM and DVD-ROM drives) wouldn't work with these boards was not going to happen for sales reasons so our code included a lockup-recovery function that was invoked when the rare bug conditions were met and the IDE bus froze. The average user never noticed these lockups and we didn't tell them about them.

      Out-of-spec bugs like this were well-known in the industry and workarounds were easy to produce as long as you had access to a few million bucks worth of test equipment and a good team of professional engineers with decades of experience, not something that's common in the Linux world.

  5. Vote with your wallet by jwkane · · Score: 4, Interesting

    Vote with your wallet, my next SSD will be a samsung.

  6. Re:Why did it only happened on Samsung's SSDs? by Anonymous Coward · · Score: 5, Insightful

    Confirmation bias. It was happening with other brands, but for one reason or another, people focused in on Samsung as the culprit, and once that happened, there was no getting out of it.

  7. Re:fairly common to blacklist devices by Midnight+Thunder · · Score: 4, Insightful

    hardware firmware is commonly buggy. Device drivers often have to work around buggy hardware, so blacklisting devices for various functionality is not at all unusual.

    If the code seems to work with other devices and breaks with a new device, then the first instinct is going to be to assume the new device is doing something wrong.

    Another way of seeing things, is even if the bug is in the kernel, black listing still prevents damage to data on said vendor's hardware. When it comes to data corruption the first thing to do is limit damage, no matter who is it at fault. Afterwards, you can work together to try to isolate source of problems. Having unhappy users and customers is never good, unless you are the competition.

    --
    Jumpstart the tartan drive.
  8. Re:not the case in my situation by Rinikusu · · Score: 4, Funny

    "But.. what does my cell phone carrier have to do with anything?"

    --
    If you were me, you'd be good lookin'. - six string samurai
  9. How was this recreated before the bug existed? by godamntheman · · Score: 4, Insightful

    Something doesn't add up ... The fix for this was an oversight in a relatively new "bio_split()" routine that merged in with the immutable bio vector patch set for Linux kernel 3.15. The Algolia blog referenced in the Samsung patch claims it was able to replicate the discard issue using kernels 3.2, 3.10, and 3.14, before the bug existed. What gives?

  10. Re:fairly common to blacklist devices by Anonymous Coward · · Score: 5, Informative

    Sorry, that's incorrect.

    There's a bug on MD raid0 and raid10. In Linux.

    There is a data destroyer bug in SAMSUNG NCQ TRIM firmware. Which is *blacklisted*, so that it uses the non-ncq trim.

    See? You're an idiot and everyone but you actually knew what they were complaining about. The samsung firmware is buggy crap that destroys data on NCQ TRIM, and the Linux kernel had a data destroyer bug in RAID0/RAID10 + TRIM that was fixed by a samsung engineer.

    The samsung firmware is still broken, the linux kernel has been fixed, and you're still an useless idiot.