Slashdot Mirror

← Back to Stories (view on slashdot.org)

TRIM and Linux: Tread Cautiously, and Keep Backups Handy

Posted by Soulskill on from the solid-state-detective-work dept.

An anonymous reader writes: Algolia is a buzzword-compliant ("Hosted Search API that delivers instant and relevant results") start-up that uses a lot of open-source software (including various strains of Linux) and a lot of solid-state disk, and as such sometimes runs into problems with each of these. Their blog this week features a fascinating look at troubles that they faced with ext4 filesystems mysteriously flipping to read-only mode: not such a good thing for machines processing a search index, not just dishing it out. "The NGINX daemon serving all the HTTP(S) communication of our API was up and ready to serve the search queries but the indexing process crashed. Since the indexing process is guarded by supervise, crashing in a loop would have been understandable but a complete crash was not. As it turned out the filesystem was in a read-only mode. All right, let's assume it was a cosmic ray :) The filesystem got fixed, files were restored from another healthy server and everything looked fine again. The next day another server ended with filesystem in read-only, two hours after another one and then next hour another one. Something was going on. After restoring the filesystem and the files, it was time for serious analysis since this was not a one time thing.

The rest of the story explains how they isolated the problem and worked around it; it turns out that the culprit was TRIM, or rather TRIM's interaction with certain SSDs: "The system was issuing a TRIM to erase empty blocks, the command got misinterpreted by the drive and the controller erased blocks it was not supposed to. Therefore our files ended-up with 512 bytes of zeroes, files smaller than 512 bytes were completely zeroed. When we were lucky enough, the misbehaving TRIM hit the super-block of the filesystem and caused a corruption."

Since SSDs are becoming the norm outside the data center as well as within, some of the problems that their analysis exposed for one company probably would be good to test for elsewhere. One upshot: "As a result, we informed our server provider about the affected SSDs and they informed the manufacturer. Our new deployments were switched to different SSD drives and we don't recommend anyone to use any SSD that is anyhow mentioned in a bad way by the Linux kernel."

120 of 182 comments (clear)

  1. Maybe we can create a superior alternative to TRIM by Rinikusu · · Score: 3, Funny

    I suggest we call it SNATCH.

    --
    If you were me, you'd be good lookin'. - six string samurai
  2. Is there a site maintaining a list of "bad" SSDs? by msobkow · · Score: 4, Interesting

    I'll Google in a moment, but I was wondering if anyone knew of any good sites that maintain lists of good/bad SSDs for Linux. With the number of vendors out there nowadays, having to scan the source seems like a poor way to track the information.

    --
    I do not fail; I succeed at finding out what does not work.
  3. Apple by Anonymous Coward · · Score: 2, Insightful

    This is why Apple doesn't support TRIM in third-party SSDs...

    1. Re:Apple by Lumpy · · Score: 2

      And it's trivial to get around.

      --
      Do not look at laser with remaining good eye.
    2. Re:Apple by drinkypoo · · Score: 2

      Sure, if you want to roll the dice.

      You roll the dice when you buy Apple equipment, just like everything else. They've had their hardware failures, and their design failures too. They simply put out less models than other companies do.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    3. Re:Apple by PlusFiveTroll · · Score: 2

      This bug has nothing to do with standard TRIM. Send TRIM as a single command after flushing the drive queue and it works fine. This has to do with the newest SATA specification allowing queued TRIM blowing up. Apple just wants to sell their more expensive drives.

    4. Re:Apple by Moridineas · · Score: 1

      Not really trivial as of Yosemite. You have to disable kernel extension signing. Luckily, there appears to be a command line tool for force enabling TRIM in 10.11.

    5. Re:Apple by DigiShaman · · Score: 1

      3rd party drive TRIM support could be publicly available in OSX El Capitan

      http://www.macrumors.com/2015/...

      "This tool force-enables TRIM for all relevant attached devices, even though they have not been validated for data integrity while using that functionality. By using this tool to enable TRIM, you agree that Apple is not liable for any consequences that may result, including but not limited to data loss or corruption."

      --
      Life is not for the lazy.
    6. Re:Apple by Lumpy · · Score: 1

      Been rolling those dice for 3 years with zero problems. Buy a quality SSD and not the cheap crap.

      --
      Do not look at laser with remaining good eye.
    7. Re:Apple by Lumpy · · Score: 1

      Still trivial even for computer n00bs.

      Download and install Trim Enabler from the app store.

      --
      Do not look at laser with remaining good eye.
    8. Re:Apple by Moridineas · · Score: 1

      True, but this has some potentially dangerous side effects.

      1) You have to disable kernel extension signing (potential security risk).
      2) If you lose PRAM, or if other hardware changes occur, your system might be in an unbootable state until you remove the TRIM kext.
      3) On my MacPro 1,1 that is running Yosemite with a non-original graphics card, I can't risk the TRIM. If, for any reason, my system were to go non-bootable, I wouldn't be able to restore, as my current graphics cards is non-Mac EFI compatible. I don't get output until the desktop loads. There are only a tiny number of people in this situation, but it effects me!

      End result, I run trim on my MBP and no trim on my MP.

  4. TRIM -- command of mass destruction by m.dillon · · Score: 5, Interesting

    The only TRIM use I recommend is running on it on an entire partition, e.g. like the swap partition, at boot, or before initializing a new filesystem. And that's it. It's an EXTREMELY dangerous command which results in non-deterministic operation. Not only do SSDs have bugs in handling TRIM, but filesystem implementations almost certainly also have ordering and concurrency bugs in handling TRIM. It's the least well-tested part of the firmware and the least well-tested part of the filesystem implementation. And due to cache effects, it's almost impossible to test it in a deterministic manner.

    You can get close to the same performance and life out of your SSD without using TRIM by doing two simple things. First, use a filesystem with at least a 4KB block size so the SSD doesn't have to write-combine stuff on 512-byte boundaries. Second, simply leave a part of the SSD unused. 5% is plenty. In fact, if you have swap space configured on your SSD, that's usually enough on its own (since swap is not usually filled up during normal operation), as long as you TRIM it on boot.

    -Matt

    1. Re:TRIM -- command of mass destruction by Anonymous Coward · · Score: 1

      It doesn't matter if your disk/partition is 95% used or not. A SSD doesn't know anything about filesystems so once a block has been written, the SSD has no way to know when that block is freed. And if your filesystem rotates through all the blocks (probably not the case of ext4, but likely for SSD-aware/specific filesystems), even if your filesystem is only 5% full, the SSD will still eventually consider the disk as full.

      TRIM is there to tell the disk that a block that was used before is now free, that it doesn't need to preserve that block's content anymore, i.e. that the disk is not actually full.

      And TRIMming on boot is fine and dandy *IF* you boot your system often enough. Servers don't reboot unless they really have to.

    2. Re:TRIM -- command of mass destruction by Anonymous Coward · · Score: 5, Informative

      Man Linux users are hilarious. TRIM has worked and been safe on every other platform for ages.

      LOL.

      Do you know who you're replying to? Matt Dillon is the principal developer of DragonflyBSD, and the HAMMER fileystem.

      While he probably does use Linux from time to time, I think you're more likely to find him at a BSD system.

    3. Re:TRIM -- command of mass destruction by guruevi · · Score: 1

      I wouldn't say that. There are plenty of stories about random SSD corruption across all platforms. Some platforms (Windows/Mac) simply do not execute TRIM unless the device is whitelisted or a proprietary piece of binary is running on the computer.

      TRIM is a kludge at best, a hack to get better performance out of shitty drives. Get a decent SSD and you won't need TRIM.

      --
      Custom electronics and digital signage for your business: www.evcircuits.com
    4. Re:TRIM -- command of mass destruction by jez9999 · · Score: 1

      Isn't TRIM support disabled by default in Linux? They must have set the "discard" mount option.

      --
      == Jez ==
      Do you miss Firefox? Try Pale Moon.
    5. Re:TRIM -- command of mass destruction by drinkypoo · · Score: 1

      Man Linux users are hilarious. TRIM has worked and been safe on every other platform for ages.

      The Intel SSD toolbox won't enable automatic TRIM support for my disk because it's some weird disk they sold to HP. TRIM claims success on it though.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
    6. Re:TRIM -- command of mass destruction by Anonymous Coward · · Score: 1

      No, the parent does not. I'll leave it to you to (try to) figure out why. I give it a 50/50 that you'll be able to.

    7. Re:TRIM -- command of mass destruction by cmaxx · · Score: 2

      *So* not a kludge. o.O

      Historically TRIM was a smart addition to block-storage commands in the enterprise SAN space, to better enable things like thin-provisioning, which at least at the time went with server virtualisation like eggs go with bacon.

      It just-so-happened that TRIM also fulfilled a very similar, and similarly smart, use-case on flash-based SSDs of all levels soon after/at the same time.

      Given the characteristics of the current flash devices in SSDs, it's a perfectly reasonable thing to add to filesystems, SANs and drives. It's vitally important that it be correctly implemented, but frankly, that's true for everything in IT.

      --
      ...an Englishman in London.
    8. Re:TRIM -- command of mass destruction by tlhIngan · · Score: 2

      No, TRIM support doesn't matter to SSDs.

      TRIM is an optimization that when properly used, can make an SSD faster. Emphasis on can, and properly used. It can also be used to reduce write amplification (the ratio of number of writes to flash over the number of writes the host computer actually did. More later).

      You can use an SSD with a non-TRIM aware OS and it will work just fine.

      In an SSD, you have pages which are mapped to sectors. As you overwrite a logical sector, the wear levelling algorithm marks the old pages as "dirty" and stores the updated contents in a new page elsewhere in the storage array. If you repeated hammer a sector, that sector's contents will be repeated across the array - there will only be one valid sector, and a bunch of older ones marked as dirty.

      Depending on SSD load, a garbage collector may have enough time to run, and it will look at each flash block, move all the pages still valid in it elsewhere, then erase the block and make it ready for use. It's not important this runs as if you issue a write and there's no free blocks, the flash controller will migrate valid sectors elsewhere and erase a block on demand.

      Note I said valid sectors - since a modern flash array may have many (128 or more) 512 byte sectors mapped to a block, rarely will all sectors be dirty at once, and long-standing data will often need to be moved elsewhere so a block can be freed up. But moving a sector incurs a write into the array, which means if you wrote the sector once at the beginning, and never touched it again, that sector may be rewritten multiple times throughout the SSD's life - so a 512 byte sector write may incur many megabytes of writes as it's moved throughout the flash array. That is write amplification - you only wrote 512 bytes, but incurred megabytes of wear on the flash. (Ideally you want 1.0 - every sector you write is written to the array exactly once)

      Now let's examine what happens with TRIM. When you delete a file, the OS merely updates a few sectors that free up the directory entry and add the disk blocks to the free bitmap. As the OS writes to the drive, the sectors belonging to the deleted file get moved about (the SSD doesn't know which sectors it no longer needs to move around), incurring write amplification and making the SSD a bit slower as it has to move sectors that the OS isn't really using.

      That's where TRIM comes in - when you delete a file, TRIM tells the SSD that the sector belongs to a deleted file, and the SSD will treat that sector as empty until the OS writes to it. It will not move the sector elsewhere as the OS said its contents were no longer relevant. This means the SSD won't need to move the contents of a deleted file around, lowering write amplification, as well as saving the need to move that sector, making the SSD faster.

      There is nothing in an SSD that requires TRIM - just that TRIM support in an OS and SSD makes storage faster and last longer. Early SSDs lacked TRIM, as did earlier OSes, so you need to be able to treat an SSD like a regular block device.

      In fact, in older SSDs, they often got slower as time went on because they were moving around deleted data - the only way to speed them up was to use an ATA_SECURE_ERASE which basically reset the entire array. Nowadays most OSes will do an equivalent TRIM if you delete the partition.

      Oh yeah, because of this, SSDs are terrible for forensics...

    9. Re:TRIM -- command of mass destruction by Agripa · · Score: 1

      Just like ZFS and similar file systems have more problems with hardware. Or was it that they detect data corruption which happens on Windows without detection or warning?

    10. Re:TRIM -- command of mass destruction by DigiShaman · · Score: 1

      So in theory, zero-ing out "free space" on an existing partition should act like a implicit TRIM command insomuch as letting the garbage collection algorithm do its thing. Right?

      --
      Life is not for the lazy.
    11. Re:TRIM -- command of mass destruction by harryjohnston · · Score: 1

      Not so. My main Windows server suffered serious problems when first deployed - not so long ago - which we eventually tracked down to the use of TRIM on the iSCSI drives.

      Granted the issues were mainly DoS rather than data loss, it was still a serious problem.

  5. Name and shame by Anonymous Coward · · Score: 2, Informative

    see ata_blacklist_entry

    (reformatted to get past Slashdot's 'junk' filter)

    static const struct ata_blacklist_entry ata_device_blacklist [] = {
    see ata_blacklist_entry

    static const struct ata_blacklist_entry ata_device_blacklist [] = /* Devices with DMA related problems under Linux */
    WDC AC11000H, NULL, ATA_HORKAGE_NODMA ,
    WDC AC22100H, NULL, ATA_HORKAGE_NODMA ,
    WDC AC32500H, NULL, ATA_HORKAGE_NODMA ,
    WDC AC33100H, NULL, ATA_HORKAGE_NODMA ,
    WDC AC31600H, NULL, ATA_HORKAGE_NODMA ,
    WDC AC32100H, 24.09P07, ATA_HORKAGE_NODMA ,
    WDC AC23200L, 21.10N21, ATA_HORKAGE_NODMA ,
    Compaq CRD-8241B, NULL, ATA_HORKAGE_NODMA ,
    CRD-8400B, NULL, ATA_HORKAGE_NODMA ,
    CRD-848[02]B, NULL, ATA_HORKAGE_NODMA ,
    CRD-84, NULL, ATA_HORKAGE_NODMA ,
    SanDisk SDP3B, NULL, ATA_HORKAGE_NODMA ,
    SanDisk SDP3B-64, NULL, ATA_HORKAGE_NODMA ,
    SANYO CD-ROM CRD, NULL, ATA_HORKAGE_NODMA ,
    HITACHI CDR-8, NULL, ATA_HORKAGE_NODMA ,
    HITACHI CDR-8[34]35,NULL, ATA_HORKAGE_NODMA ,
    Toshiba CD-ROM XM-6202B, NULL, ATA_HORKAGE_NODMA ,
    TOSHIBA CD-ROM XM-1702BC, NULL, ATA_HORKAGE_NODMA ,
    CD-532E-A, NULL, ATA_HORKAGE_NODMA ,
    E-IDE CD-ROM CR-840,NULL, ATA_HORKAGE_NODMA ,
    CD-ROM Drive/F5A, NULL, ATA_HORKAGE_NODMA ,
    WPI CDD-820, NULL, ATA_HORKAGE_NODMA ,
    SAMSUNG CD-ROM SC-148C, NULL, ATA_HORKAGE_NODMA ,
    SAMSUNG CD-ROM SC, NULL, ATA_HORKAGE_NODMA ,
    ATAPI CD-ROM DRIVE 40X MAXIMUM,NULL,ATA_HORKAGE_NODMA ,
    _NEC DV5800A, NULL, ATA_HORKAGE_NODMA ,
    SAMSUNG CD-ROM SN-124, N001, ATA_HORKAGE_NODMA ,
    Seagate STT20000A, NULL, ATA_HORKAGE_NODMA ,
    2GB ATA Flash Disk, ADMA428M, ATA_HORKAGE_NODMA , /* Odd clown on sil3726/4726 PMPs */
    Config Disk, NULL, ATA_HORKAGE_DISABLE , /* Weird ATAPI devices */
    TORiSAN DVD-ROM DRD-N216, NULL, ATA_HORKAGE_MAX_SEC_128 ,
    QUANTUM DAT DAT72-000, NULL, ATA_HORKAGE_ATAPI_MOD16_DMA ,
    Slimtype DVD A DS8A8SH, NULL, ATA_HORKAGE_MAX_SEC_LBA48 ,
    Slimtype DVD A DS8A9SH, NULL, ATA_HORKAGE_MAX_SEC_LBA48 , /* Devices we expect to fail diagnostics */ /* Devices where NCQ should be avoided */ /* NCQ is slow */
    WDC WD740ADFD-00, NULL, ATA_HORKAGE_NONCQ ,
    WDC WD740ADFD-00NLR1, NULL, ATA_HORKAGE_NONCQ, , /* http://thread.gmane.org/gmane.linux.ide/14907 */
    FUJITSU MHT2060BH, NULL, ATA_HORKAGE_NONCQ , /* NCQ is broken */
    Maxtor *, BANC*, ATA_HORKAGE_NONCQ ,
    Maxtor 7V300F0, VA111630, ATA_HORKAGE_NONCQ ,
    ST380817AS, 3.42, ATA_HORKAGE_NONCQ ,
    ST3160023AS, 3.42, ATA_HORKAGE_NONCQ ,
    OCZ CORE_SSD, 02.10104, ATA_HORKAGE_NONCQ , /* Seagate NCQ + FLUSH CACHE firmware bug */
    ST31500341AS, SD1[5-9], ATA_HORKAGE_NONCQ |
    ATA_HORKAGE_FIRMWARE_WARN ,
    ST31000333AS, SD1[5-9], ATA_HORKAGE_NONCQ |
    ATA_HORKAGE_FIRMWARE_WARN ,
    ST3640[36]23AS, SD1[5-9], ATA_HORKAGE_NONCQ |
    ATA_HORKAGE_FIRMWARE_WARN ,
    ST3320[68]13AS, SD1[5-9], ATA_HORKAGE_NONCQ |
    ATA_HORKAGE_FIRMWARE_WARN , /* Seagate Momentus SpinPoint M8 seem to have FPMDA_AA issues */
    ST1000LM024 HN-M101MBB, 2AR10001, ATA_HORKAGE_BROKEN_FPDMA_AA ,
    ST1000LM024 HN-M101MBB, 2BA30001, ATA_HORKAGE_BROKEN_FPDMA_AA , /* Blacklist entries taken from Silicon Image 3124/3132
    Windows driver .inf file - also several Linux problem reports */
    HTS541060G9SA00, MB3OC60D, ATA_HORKAGE_NONCQ, ,
    HTS541080G9SA00, MB4OC60D, ATA_HORKAGE_NONCQ, ,

    1. Re:Name and shame by Rockoon · · Score: 4, Interesting

      The way I am reading the comments, the issue is that the buggy SSD's are flagging physical blocks as RZAT or DRAT when a trim request on a logical block is ignored. The bug presents itself later if the SSD performs wear leveling that swaps out the logical block with another, the bug being leaving the physical block tagged RZAT or DRAT.

      --
      "His name was James Damore."
  6. Re:Maybe we can create a superior alternative to T by future+assassin · · Score: 1

    No we need a TRIM standard first.

    --
    by TheSpoom (715771) Uncaring Linux user here. I have nothing to add to this but please continue. *munches popcorn*
  7. so it had nothing to do with Linux by Anonymous Coward · · Score: 1

    Just typical crappy SSD firmware. Writing 0s to the wrong fucking block will trip up any OS!

  8. TLDR by Anonymous Coward · · Score: 2, Insightful

    Don't buy Samsung SSDs.

    1. Re:TLDR by Yunzil · · Score: 1

      Yeah, don't buy arguably the best SSDs on the market because your OS can't be bothered to work around their foibles.

  9. Algolia? by Hognoxious · · Score: 1

    Algolia is a buzzword-compliant ("Hosted Search API that delivers instant and relevant results") start-up

    It sounds like a kind of infection. The kind you get, you know, down there

    --
    Confucius say, "Find worm in apple - bad. Find half a worm - worse."
  10. Re:Is there a site maintaining a list of "bad" SSD by Anonymous Coward · · Score: 1

    Linus is on vacation so you'll have to wait on your next SSD purchase for him to return to merge the patches....

  11. So dont use cheap consumer ssd's by silas_moeckel · · Score: 1

    Or if your going to use consumer ones vet the hell out of them.

    --
    No sir I dont like it.
    1. Re:So dont use cheap consumer ssd's by SuricouRaven · · Score: 1

      I suspect that what we see here is a problem that is very common in the consumer hardware industry: manufacturers don't bother testing under any OS other than Windows, which means bugs that do not manifest under Windows go undetected. It's a problem most often seen in ACPI interfaces, where Windows has a very loose interpretation of the standards. So long as it runs fine on Windows, it's considered good enough to ship.

    2. Re:So dont use cheap consumer ssd's by Gallomimia · · Score: 1

      I suspect that what we see here is a problem that is very common in the consumer hardware industry: manufacturers don't bother testing under any OS other than Windows, which means bugs that do not manifest under Windows go undetected. It's a problem most often seen in ACPI interfaces, where Windows has a very loose interpretation of the standards. So long as it runs fine on Windows, it's considered good enough to ship.

      Sounds like the old internet exploder market share standards hijacking. Typical microsoft. If computer users were like navies of countries, and corporations like M$ were private ships, we'd all refer to it as the Titanic of Infotech. Or the Lusitania. Sunk.

      --
      Sadly, a Libertarian cannot force his views on another, and freedom cannot spread as does the cancer known as religion.
  12. Apple TRIM Whitelist? by LDAPMAN · · Score: 3, Interesting

    I wonder if this issue has anything to do with why Apple only supports TRIM on specific drives they OEM?

    1. Re:Apple TRIM Whitelist? by Anonymous Coward · · Score: 2, Insightful

      Yes. Apple also has custom firmware to support temperature sensors (instead of just using the standard SMART commands), which is why the fans in their iMacs/Macbooks will run at full speed if you swap out their drive for a 3rd party one... OS X assumes that the sensor is broken and goes into safe mode to avoid an overtemp burnout.

    2. Re:Apple TRIM Whitelist? by Anonymous Coward · · Score: 5, Insightful

      Its a good bet.

      As apple is probably quite aware, being probably the biggest seller of non-windows PCs, there is an endemic problem with a whole lot of hardware shipped claiming to be "compliant" with any given standard.

      Most vendor's testing methodology pretty much comes down to "Works on windows? Ship it"

      Linux has been dealing with this problem for decades. Power management implementations in laptops (and some desktop motherboards) are often outright broken and don't behave anything close to what the "standard" dictates. (Its so bad in laptops that Microsoft's power management maintains a hardware checklist with custom hacks for laptops with known bad implementations. On many systems it does not even /attempt/ to use standard calls)

      Linux developers attempt to access hardware in a manner according to how documented standards state and end up tripping all sorts of bugs from mild to hardware-bricking. Flabbergasted hardware vendors often respond with "It works in windows!"

      (Fortunately this shit doesn't fly in the server space where Linux is now pretty much King.. Well, at least in theory)

      So yes, I'd be willing to bet that Apple found that enabling trim in any old SSD led to an unacceptable chance of filesystem corruption and decided to implement a white list. So, you know, they don't catch shit for someone else's broken hardware.

    3. Re:Apple TRIM Whitelist? by Algan · · Score: 1

      I will have to call BS on this one. Both my MBP and my old school MP run 3rd party drives, including SSDs (Crucial and OCZ - yeah, I know). No problems whatsoever so far, fans are spinning at their normal rpm.

      --
      If con is the opposite of pro, is Congress the opposite of progress?
    4. Re:Apple TRIM Whitelist? by AmiMoJo · · Score: 1

      If that was the reason they would just make sure to never send queued TRIM commands like Windows does for all drives and Linux does for known bad drives. The performance loss is minimal, especially on Windows where TRIM commands are sent when the drive is idle anyway for performance reasons.

      Instead they just disabled it for all but their own drives. Seems more like a way to discourage people from buying non-Apple SSDs (which are rather expensive) by crippling performance for no good reason.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    5. Re:Apple TRIM Whitelist? by Gallomimia · · Score: 1

      They crippled performance on platter drives too. 10.6 booted way faster than 10.10 launched apps faster, played games faster, browsed web faster.

      --
      Sadly, a Libertarian cannot force his views on another, and freedom cannot spread as does the cancer known as religion.
    6. Re:Apple TRIM Whitelist? by DigiShaman · · Score: 1

      The Apple white list only has one line item looking for (wait for it)..APPLE! In other words, if the drive isn't tagged as Apple being the vendor, TRIM doesn't get enabled. Previous hacks disabled the Apple vendor check to enable TRIM on drives that could physically support it.

      --
      Life is not for the lazy.
  13. Re:Maybe we can create a superior alternative to T by Anonymous Coward · · Score: 1

    The classic landing strip is a safe default.

  14. What is Windows doing differently? by PhrostyMcByte · · Score: 1

    I have an 850 Pro at home and an 850 EVO at work, and haven't experienced any corruption. I know that Windows uses TRIM. Why am I not seeing any problems?

    I doubt EXT4 or whatever part of Linux issuing TRIM commands is doing it wrong, but they're clearly doing it different, and maybe it can be worked around or at the very least reported to the manufacturer to fix broken firmware.

    1. Re:What is Windows doing differently? by Gaygirlie · · Score: 1

      I came to comment on that: after Googling for a bit I actually cannot find any mention of Samsung SSD 840 PRO having issues with TRIM under Windows. If it was, indeed, a controller - problem then it would have to happen under all OSes as long as TRIM is enabled, but all the evidence I'm finding only points towards to Linux or these guys' setup as being the culprit.

      Disclaimer: I do not own one of these drives, so I can't speak from personal experience.

    2. Re:What is Windows doing differently? by thegarbz · · Score: 1

      I can add an anecdote. 2x 840 evo pros at home and 1 840 evo running windows 7, 8.1 and 7 respectively. Never had any kind of corruption issue. Mind you none of these drives are under any serious load like search indexing.

    3. Re:What is Windows doing differently? by guruevi · · Score: 1

      Does your OS actually do TRIM or is it merely reporting that it supports TRIM? Or does it require a binary to execute TRIM? I've noticed, most devices are simply ignoring TRIM commands. Also, do you actually continuously verify that your data is written and stored correctly? Unless you have ZFS or BTRFS, you most likely are accumulating errors across your data.

      --
      Custom electronics and digital signage for your business: www.evcircuits.com
    4. Re:What is Windows doing differently? by LDAPMAN · · Score: 1

      These guys are running a very out of the ordinary usage profile and they have also managed to identify the root cause. It's possible it happens rarely with more normal usage and that none has bothered to find the root cause.

    5. Re:What is Windows doing differently? by viperidaenz · · Score: 1

      How is ZFS or BTRFS going to help you?

      Sounds like the corruption occurs due to the trim command erasing data that has already been successfully written.

      Sure, ZFS will tell you if you're reading corrupt data, but by then it's too late, your data is gone.

    6. Re:What is Windows doing differently? by thegarbz · · Score: 1

      Yes I've checked it on the windows 7 machines, not on the windows 8.1 (just assumed it was on as it was with windows 7).

      Also no I don't continuously verify data. These drives store only program info on them. If I were accumulating errors on the data at any kind of problematic rate then I would have started seeing random crashes / bluescreens sometime over the past few years, which I haven't.

      Errors are errors, and there's ways of noticing them other than continuous checksumming.

    7. Re:What is Windows doing differently? by Gaygirlie · · Score: 1

      Or does it require a binary to execute TRIM?

      Windows supports TRIM out of the box, there is no need for any 3rd-party executables for that.

      Also, do you actually continuously verify that your data is written and stored correctly? Unless you have ZFS or BTRFS, you most likely are accumulating errors across your data.

      That's a silly claim that people love to spread around. If there were errors accumulating across the data then sooner or later you'd notice it, either with broken files when you're trying to open them or crashing/non-working executables and/or OS. Most home-users don't use SSDs to just store rarely-used files, they're used for, you know, speeding up the OS and applications that are often in use and to store stuff like home-dirs -- you'd very quickly notice corruptions if they did happen.

    8. Re:What is Windows doing differently? by Gaygirlie · · Score: 1

      and they have also managed to identify the root cause

      No, they managed to identify *a* cause, not *the* cause. If TRIM works fine under other OSes, but not Linux, then Linux is doing something differently and that in and of itself isn't yet enough proof to make a claim that the fault lies in the OS or that it lies in the controller -- it could even be both! Finding the actual root cause requires still quite a bit more work than that.

    9. Re:What is Windows doing differently? by Anonymous Coward · · Score: 1

      There are two TRIM commands, queued and non-queued. People commenting here don't understand the difference between the two and the the article is about the latter. Windows does not issue queued by default.

    10. Re:What is Windows doing differently? by Gaygirlie · · Score: 1

      Linux uses a more modern and performant variant of TRIM, namely queued TRIM

      Except that's irrelevant, the guys didn't use queued TRIM either. It says in the article itself that they used non-queued TRIM.

    11. Re:What is Windows doing differently? by KGIII · · Score: 1

      According to an update an another posting at a different site (see up-thread) this is not a queued TRIM issue but is a TRIM issue.

      --
      "So long and thanks for all the fish."
    12. Re:What is Windows doing differently? by Gallomimia · · Score: 1

      I notice it. But I copy and recopy old data to multiple devices and different forms of media (ie optical) there's lots of losses and errors all over the place. After a few copies and years of storage things happen. I've even noticed two different TV series having blocks of data mixed between them. Odd color-shifted scenes from the wrong series interspersed into another that was copied with it. It's not a silly claim; what's silly is you trying to refute it with no evidence.

      --
      Sadly, a Libertarian cannot force his views on another, and freedom cannot spread as does the cancer known as religion.
    13. Re:What is Windows doing differently? by Gaygirlie · · Score: 1

      with no evidence.

      So, your personal experience counts as evidence, but mine doesn't?

  15. Re:Is there a site maintaining a list of "bad" SSD by Ken_g6 · · Score: 5, Informative

    It takes a couple of links and searching through source code to get there. So here's the list of problematic drives, better formatted but still in regular expression format:

    /* devices that don't properly handle queued TRIM commands */
    Micron_M500*
    Crucial_CT*M500*
    Micron_M5[15]0*
    Crucial_CT*M550*
    Crucial_CT*MX100*
    Samsung SSD 8*

    So, basically, all the ones I thought were the best. The list of whitelisted drives after it only includes those brands, Intel, and ST-something. So other brand may be unknowns.

    --
    (T>t && O(n)--) == sqrt(666)
  16. Re:Is there a site maintaining a list of "bad" SSD by Anonymous Coward · · Score: 1

    From the link to the original article:

    Broken SSDs:

    SAMSUNG MZ7WD480HCGM-00003
    SAMSUNG MZ7GE480HMHP-00003
    SAMSUNG MZ7GE240HMGR-00003
    Samsung SSD 840 PRO Series
    recently blacklisted for 8-series blacklist
    Samsung SSD 850 PRO 512GB
    recently blacklisted as 850 Pro and later in 8-series blacklist

    Working SSDs:
    Intel S3500
    Intel S3700
    Intel S3710

    See also https://github.com/torvalds/linux/blob/e64f638483a21105c7ce330d543fa1f1c35b5bc7/drivers/ata/libata-core.c#L4109-L4286

  17. Re:trim by Nkwe · · Score: 2

    "we don't recommend anyone to use any SSD that is anyhow mentioned in a bad way by the Linux kernel"

    ???? SERIOUSLY???

    While poorly written, I think the author was suggesting that any model of SSD for which the Linux kernel has specific special handling logic should be avoided. In my opinion, it is not an unreasonable statement.

  18. Re:Is there a site maintaining a list of "bad" SSD by Anonymous Coward · · Score: 5, Informative

    The Crucial MX100 with the latest MU02 firmware is now whitelisted by the Linux Kernel, and has it's TRIM ability re-enabled.

  19. Re:And the offending SSD drives are.... by ihtoit · · Score: 2

    it's a long list, apparently... the whitelist is shorter. I'd go with the Apple one. They seem to have their QA department high and tight.

    --
    Political debates have me rolling my eyes so much I think I got optical whiplash. I should sue. - Foamy The Squirrel
  20. Another Deceptive Slashdot Title by idontgno · · Score: 4, Insightful

    Correct title: "TRIM and Any Fucking Operating System: Don't Buy Defective SSDs"

    It's not as if Windows or MacOS has any magic that makes queued TRIM work with non-compliant and poorly-coded hardware, right?

    Seriously, WTF, over?

    --
    Welcome to the Panopticon. Used to be a prison, now it's your home.
    1. Re:Another Deceptive Slashdot Title by Anonymous Coward · · Score: 3, Informative

      Windows and MacOS do not issue Queued TRIM in the first place. They only issue the regular TRIM command, which has to stop all data in flight and quiesce the entire submission queue (all tags, etc).

      Linux is ultra-high-IO-load optimized, queued TRIM is a must when dealing with high-performance storage (not just SSDs). Maybe it should stop trusting devices that are neither attached to a SAS or FC transport by default when they claim to actually implement advanced features, though.

    2. Re:Another Deceptive Slashdot Title by Trogre · · Score: 4, Insightful

      Dear Microsoft,

      Thank you for your generous donation to our staff social club. As promised, please find attached drivers that utilise the *real* TRIM commands for our SSDs.

      Sincerely yours,
      A. Manufacturer

      --
      "Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife
    3. Re:Another Deceptive Slashdot Title by amiga3D · · Score: 1, Informative

      It's a buggy hardware issue. How each operating system deals with it may vary but the entire dilemma results from shitty hardware.

    4. Re:Another Deceptive Slashdot Title by Anonymous Coward · · Score: 1

      Always entertaining to read the mental gymnastics Linux zealots go through to defend the honor of their OS.

    5. Re:Another Deceptive Slashdot Title by tlhIngan · · Score: 1

      It's not as if Windows or MacOS has any magic that makes queued TRIM work with non-compliant and poorly-coded hardware, right?

      OS X disables TRIM on third-party SSDs by default. On Mavericks and below, there's an app called TRIM Enabler that enables TRIM on third-party SSDs. On Yosemite, kernel signing prevents this from happening, resulting in a really sketchy method to get TRIM operational.

      El Capitan is supposed to come with a way to enable TRIM on third-party SSDs, but it requires special modes and using the command line to enable it.

      I suppose Windows makes everyone thing TRIM just works, while Apple and Linux have experienced problems which is why TRIM is more problematic.

      On Linux, I manually TRIM using fstrim - just put it in your cron.weekly or something.

    6. Re:Another Deceptive Slashdot Title by John+Allsup · · Score: 1

      "queued TRIM is a must when dealing with high-performance storage (not just SSDs)"??

      TRIM is not used by anything other than flash storage.

      --
      John_Chalisque
    7. Re:Another Deceptive Slashdot Title by jabuzz · · Score: 1

      Wrong it is used with thin provisioning in enterprise storage products. That is I can thinly provision a volume on my storage array and it will use the TRIM commands to "reuse" blocks that are no longer needed in exactly the same way flash drive would.

    8. Re:Another Deceptive Slashdot Title by AmiMoJo · · Score: 1

      https://en.wikipedia.org/wiki/...

      TRIM is explicitly a non-queued command. Linux attempting to queue it is out of spec. It works most of the time, but it isn't fair to say lay all the blame for failures with the SSD manufacturers. They should reject queued TRIM commands if they don't work, but equally Linux should not be sending them.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
    9. Re:Another Deceptive Slashdot Title by mr_mischief · · Score: 1

      Perhaps you should update your lovely Wikipedia page, because it is outdated.

      SATA 3.1 standard note at techreport
      Webopedia info on SATA 3.x
      Wikipedia's own entry on SATA 3.1
      TechPowerUp article about SATA 3.1

      Here's a press release from sata-io about it: in PDF format

      Not only does TRIM via NCQ exist, it is in the recent specifications. You see, the thing about computer technology is that it keeps being improved. Outdated information doesn't stop that. It just becomes outdated.

    10. Re:Another Deceptive Slashdot Title by Agripa · · Score: 1

      https://en.wikipedia.org/wiki/... [wikipedia.org]

      TRIM is explicitly a non-queued command. Linux attempting to queue it is out of spec. It works most of the time, but it isn't fair to say lay all the blame for failures with the SSD manufacturers. They should reject queued TRIM commands if they don't work, but equally Linux should not be sending them.

      From your link:

      This Trim shortcoming has been overcome in Serial ATA revision 3.1 with the introduction of the Queued Trim Command.

      If the drives were not reporting support for this command which they do not support, then there would not be a problem.

  21. Re:Is there a site maintaining a list of "bad" SSD by idontgno · · Score: 5, Informative

    ObPedant: those aren't regexes, they're globs. Otherwise (for instance), the Samsung entry would match

    Samsung SSD<space>
    Samsung SSD<space>8
    Samsung SSD<space>88
    Samsung SSD<space>888
    .
    .
    .

    ad nauseam: the "*" regex operator means "zero or more occurrences of the previous pattern", which in this case is the character "8".

    At least, I hope they're not supposed to be regexes. Otherwise, the kernel blacklist itself will have some serious issues known-bad SSDs because someone never learned how to create a regular expression.

    --
    Welcome to the Panopticon. Used to be a prison, now it's your home.
  22. Re:Is there a site maintaining a list of "bad" SSD by Anonymous Coward · · Score: 4, Informative

    There's also an upgrade path for Micron's older SSDs - I just upgraded my Crucial M550 from MU01 to MU02 using a bootable ISO from Micron's support site:

          http://www.crucial.com/usa/en/support-ssd-firmware

  23. Re:Is there a site maintaining a list of "bad" SSD by Gaygirlie · · Score: 4, Interesting

    Not directly an answer to your question, but related: after Googling for a bit I actually cannot find any mention of Samsung SSD 840 PRO having issues with TRIM under Windows. If it was, indeed, a controller - problem then it would have to happen under all OSes as long as TRIM is enabled, but all the evidence I'm finding only points towards to Linux or these guys own setup as being the culprit.

  24. Re:Is there a site maintaining a list of "bad" SSD by FatdogHaiku · · Score: 3, Funny

    Linus is on vacation so you'll have to wait on your next SSD purchase for him to return to merge the patches....

    What? "The most influential individual economic force of the past 20 years" gets to just wander off?

    --
    You have the right to remain sentient. If you give up the right to remain sentient, you will be elected to public office
  25. Re:Software RAID issue with SSDs? by sexconker · · Score: 2

    Your RAID controller would have to pass the TRIM commands to the SSDs in the array for this bug to show up. The controller simply having TRIM support doesn't mean it actually passes it to drives that are part of an array.
    Intel controllers since the Z-77 do pass TRIM along to the drives in the array, but only for RAID 1 and RAID 0.

  26. Re:Is there a site maintaining a list of "bad" SSD by Anonymous Coward · · Score: 1, Insightful

    Linux probably tickles a bug in the SSD. This is the problem with things only being validated within Windows.

  27. Re:Is there a site maintaining a list of "bad" SSD by MrBingoBoingo · · Score: 3, Interesting

    There is are two easy solutions to Ext4 vs. SSD problems. The first is ReiserFS which is still eminently usable on Gentoo. The second is UFS which is available on the BSD's.

  28. Re:And the offending SSD drives are.... by Bing+Tsher+E · · Score: 1

    You could even hunker on down to the Apple Store to buy their OEM drive. They love this kind of thing at the Apple store.

  29. Re:Is there a site maintaining a list of "bad" SSD by Anonymous Coward · · Score: 2, Insightful

    I assume that Windows does not submit queued trim commands, thereby avoiding this problem.

  30. Re:Is there a site maintaining a list of "bad" SSD by Anonymous Coward · · Score: 2

    You will only find SSDs from the very best vendors there... because the crap ones don't claim to support queued TRIM in the first place.

    It is interesting that the Micron M500, *which is an enterprise datacenter SSD*, is listed. Rather bad PR for Micron, that: an enterprise datacenter SSD that corrupts data and has not been fixed?!

    As usual, good PR for Intel... too bad their SSDs self-destruct based on a timer, instead of trying to soldier on until things actually get really broken (and only *then* self-destruct).

  31. Just not worth it by iamacat · · Score: 1

    Even when implemented correctly, TRIM slows down regular I/O that happens around the time it's done. On top of that, you are risking OS and drive bugs that can vary with every incremental revision. You may not notice corruption until all your backups are overwritten, and just think of a hassle of restoring even once. Is it really worth potential minor performance benefits that are often realized by drive itself anyway?

    I can think of exceptions like building a supercomputer with monolithic array of drives uses for disposable cache. But for individual users TRIM makes no sense.

    1. Re:Just not worth it by fnj · · Score: 1

      Use of TRIM fights the deleterious effect of write amplification on lifespan, as well as reducing degradation of performance over time. Why does that "make no sense" for individual users?

      There are two strategies for using TRIM.

      The first one is "discard" in the mount options, which causes the drive to be informed via the TRIM command at the time a block is freed (file erased). The second strategy runs a utility (fstrim) periodically - for example, once a day - to TRIM all the blocks freed since the last time.

      The first strategy somewhat slows down each delete in normal operation, and is considered to be dangerous. For this reason the second strategy is considered to be preferable. It is not clear to me why grouping the TRIMs and executing the groups infrequently is considered safer. But I have used the second strategy for a long time on my M500 SSD and never discovered any corruption.

      References: 1, 2, 3

  32. SSDs are not HDDs so DO keep backups ALWAYS handy by kosmosik · · Score: 1

    I only have experience with customer grade SSDs and not with enterprise ones. But as it comes for customer SSDs most of the ones I've used or maintained caused no problems. But I recall one HP made drive that used crash after about a year - total data loss after a year of usage. Reformat and the drive was ok - another year passed and crash and data loss. As it turned out the disk had some encryption procedures in firmware which were faulty - firmware upgrade (hopefully) fixed it but also said firmware update required to erease all data. I've always had decent backups as monthly system image and daily data so recovery was easy. But I am aware that SSD drives are much less reliable than HDDs due to controller/firmware problems. And this is IMHO a general known fact.

  33. Re:Is there a site maintaining a list of "bad" SSD by Trogre · · Score: 1

    As usual, good PR for Intel... too bad their SSDs self-destruct based on a timer, instead of trying to soldier on until things actually get really broken (and only *then* self-destruct).

    Wait, what?

    --
    "Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife
  34. Re:Is there a site maintaining a list of "bad" SSD by drinkypoo · · Score: 4, Insightful

    Wait, what?

    When Intel SSDs decide they are bad, they just brick themselves instead of going into read-only-good-luck-your-data-may-be-bad-mode. This probably makes sense for Enterprise RAID, and for absolutely no other use case.

    --
    "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
  35. Re:Btrfs? by BitZtream · · Score: 3, Informative

    COW doesn't solve the problem that TRIM solves.

    Once you write over the entire drive once, then all blocks of flash are dirty and MUST be erased before any new writes can take place. At this point, you can't even write the meta data without a sector erase, then you can write to it ... just to tell it that you've added another ref to an existing block.

    With TRIM, blocks are erased when they are no longer used, so they do not need an erase cycle when before writing to them.

    I don't use BTRFS, but do use ZFS and it most certainly benefits from TRIM on an active drive, which is certainly what all your SSDs are going to be.

    --
    Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
  36. Re:Is there a site maintaining a list of "bad" SSD by KarateBob · · Score: 1

    how is f2fs now-a-days?

  37. Re:Btrfs? by sshir · · Score: 1

    That's why i've added overprovisioning to my message (you've read it right?). And, by the way, all drives have reserved blocks to counteract things like scenario you've described. And I actually do use BTRFS on a very write active drive - works like a charm.

  38. Re:Is there a site maintaining a list of "bad" SSD by PlusFiveTroll · · Score: 4, Informative

    Because Windows doesn't do queued TRIM.

    TRIM in Windows and Linux before now worked more like this. -DATA- -DATA- -FLUSH ALL COMMANDS TO DRIVE- -WAIT- -TRIM- -DATA- -DATA- When I drive was doing the trim thing it could not do anything else, there could be no other in flight commands to the drive.

    This is different. -DATA- -DATA- -TRIM- -DATA- -TRIM- -DATA- -DATA- -DATA-

    TRIM is part of the NCQ and is an operation occurring with other instructions in the SATA queue. Problem is some disk manufactures have pissed this up. It seems likely that a firmware update will be able to fix this issue.

    https://en.wikipedia.org/wiki/...

  39. Re:Is there a site maintaining a list of "bad" SSD by Billly+Gates · · Score: 1

    Yep freebsd is fine here with 840 pros.

    I find it hysterical that it must be the drives attitude on this heavily biased site towards linux.

    --
    http://saveie6.com/
  40. Re:Is there a site maintaining a list of "bad" SSD by complete+loony · · Score: 4, Informative
    From the SSD Endurance Experiment;

    The drive's media wear indicator ran out shortly after 700TB, signaling that the NAND's write tolerance had been exceeded. Intel doesn't have confidence in the drive at that point, so the 335 Series is designed to shift into read-only mode and then to brick itself when the power is cycled. Despite suffering just one reallocated sector, our sample dutifully followed the script. Data was accessible until a reboot prompted the drive to swallow its virtual cyanide pill.

    --
    09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
  41. Re:Is there a site maintaining a list of "bad" SSD by Anonymous Coward · · Score: 1, Insightful

    Well when FreeBSD gets around to supporting queued TRIM, people like yourself can thank Linux devs and users for getting the manufacturers to fix their firmware.

    Some men choose to walk the paths others have created, while some venture forth and create their own.

  42. That's too long by drinkypoo · · Score: 1

    We should use CUT. Although that might conflict with a builtin in the Gnu assisted shell.

    --
    "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
  43. Re:trim by drinkypoo · · Score: 1

    While poorly written, I think the author was suggesting that any model of SSD for which the Linux kernel has specific special handling logic should be avoided. In my opinion, it is not an unreasonable statement.

    It probably is an unreasonable statement. If Linux has special logic to handle the drive, then someone else probably already had the problem and now there's a fix in so it probably won't happen to you.

    --
    "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
  44. Article author wasn't using queued TRIM by Sits · · Score: 1

    The article now contains an update stating that queued TRIM was not involved (that ordinary TRIM was to blame is also mentioned in the author's Hackers News comment) only ordinary TRIM. It also appears that the company's drives were enterprise Samsung PROs.

    1. Re:Article author wasn't using queued TRIM by Eunuchswear · · Score: 1

      It also appears that the company's drives were enterprise Samsung PROs.

      Yeah, right, "enterprise" disks with SATA interfaces. Buy crap, get crap.

      --
      Watch this Heartland Institute video
  45. Re:trim by Nkwe · · Score: 3, Interesting

    While poorly written, I think the author was suggesting that any model of SSD for which the Linux kernel has specific special handling logic should be avoided. In my opinion, it is not an unreasonable statement.

    It probably is an unreasonable statement. If Linux has special logic to handle the drive, then someone else probably already had the problem and now there's a fix in so it probably won't happen to you.

    Perhaps. But if the drive was broken and someone had to write special software to fix it, how can you be sure that it was fixed correctly and completely? Can you also be sure that the "fix" works for all versions of firmware on the drive? While you might be confident of these things, I would suggest that it would be better to use a drive that follows the standards and doesn't require special code to make it work right. Granted that as always, your mileage may vary -- and it could vary in either direction.

  46. Re:Btrfs? by fnj · · Score: 1

    ZFS is COW and still cannot magically eliminate rrandom writes due to fragmentation as it gets near full. I daresay all filesystems have this problem to a degree. Reserved blocks and over-provisioning in no way can prevent it.

    Reserved blocks are solely present to allow bad-block replacement. Over-provisioning adds to the general pool of available blocks, but as soon as they are used they have to be erased before re-use, just like any other block. As your writes cumulatively total multiples of the capacity of the drive, over-provisioned or not, you end up with exactly the same situation that TRIM is intended to address.

    Whether all blocks are written to when you have written 1.0 times the capacity of the drive (no over-provisioning), or 1.5 times the capacity (strongly over-provisioned), this occurs when only a tiny fraction of the drive endurance limit is reached.

  47. For anyone bothered by nonsense constructions... by fnj · · Score: 1

    FTFS:

    Our new deployments were switched to different SSD drives

    Is "SSD drive" grammatically anything like "PIN number"?

  48. Re:Is there a site maintaining a list of "bad" SSD by TCM · · Score: 1

    When it comes to IT, I'll gladly let the hipsters deal with the pain and the data loss for a 0.5% speedup and use whatever they came up with - and is still relevant - after 10 years. Thank you very much.

    --
    Of course it runs NetBSD. BTC: 1NT7QvbetmANwaMzhpVL6
  49. Re: Is there a site maintaining a list of "bad" SS by Bert64 · · Score: 3, Interesting

    If your booting from the SSD, chances are the machine will crash...
    Would be much better to just stay in readonly mode, and give you the chance to copy data off (and yes im aware this is no substitute for a backup, but think of the use case of a travelling laptop far away from its backup server etc).

    --
    http://spamdecoy.net - free throwaway anonymous email - avoid spam!
  50. Re:Mentioned in a bad way by the Linux kernal? by Mike+Frett · · Score: 3, Funny

    I could shove a dead Rat in the CPU slot and Windows would work with errors galore while Linux would actually tell me I have a dead Rat in the CPU slot. Linux exposes bad Hardware.

  51. TRIM vs NCQ by DrYak · · Score: 1

    But if the drive was broken and someone had to write special software to fix it, how can you be sure that it was fixed correctly and completely? Can you also be sure that the "fix" works for all versions of firmware on the drive?

    Because the fix is relatively simple.

    To put in general terms:
    - The problem is that the drive advertises a bunch of features. Linux tries to use them. But the firmware is buggy and the feature don't work or aren't even implemented.
    - The fix is to ignore any advanced feature even if advertised by firmware. Stick to only the small subset of features that are also used in windows.

    e.g:
    - the most frequent problem with trim is that the device advertises supporting TRIM with NCQ (= reordering of commands).
    (the latest firmware for Samsung 840 EVO started advertising this in addition of fixing the speed decay).
    Linux *can* issue TRIM together with NCQ. So when the drives says it does, it will start using it.
    But the drives doesn't work with TRIM and NCQ combined. There's a bug in the implementeation, or the firmware doesn't even support it.
    (no Samsung 8?? actually support TRIM+NCQ. It's falsely reported as present by the firmware).
    - Windows (and perhaps Mac OS X) aren't affected by this because they don't support it to begin with.
    - Linux fix is to simply ignore the falsely advertised TRIM+NCQ. It reverts to either use NCQ, or use TRIM in a blocking (slow) way.
    And that is a permanent fix because is simply reverts to a behavious similar to windows. No new problem should arise in Linux because it simply mimics the behaviour of Windows. If anything was still broken, it would be affecting Windows too.
    It will work against any version of the firmware (Linux isn't tricking the firmware or trying to compensate. Just plain ignoring missing features).

    Of course, the best would be to use 100% standard compliant SSD.
    But reality is that not much *are* actually standard compliant.

    So unless you're ready to shell lots of money for some actually enterprise-grade SSD,
    accepting SSD with patched support is the next best option.

    --
    "Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
    1. Re:TRIM vs NCQ by mr_mischief · · Score: 1

      It will break if some model of drive from the same manufacturer is also buggy but the model number happens not to match the list of regexes. That's why they recommend steering clear. If the regex match correctly keeps up with all the buggy drives, there's no problem.

    2. Re:TRIM vs NCQ by drinkypoo · · Score: 1

      It will break if some model of drive from the same manufacturer is also buggy but the model number happens not to match the list of regexes.

      Right, so that's another reason not to buy a disk which isn't mentioned in kernel errata. Any new device may have unknown bugs. Thanks for really driving my point home.

      --
      "You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
  52. TRIM+NCQ by DrYak · · Score: 2

    it's not trim by itself that is problematic.
    it's the combined use with NCQ (= reordering of commands).

    The latest firmware (the one that fixes the speed decay) has started to falsely advertise support for this combination, whereas the drive doesn't actually support it.
    The drive isn't actually able to re-order TRIM commands, and the wrong bit might end up being erased due to NCQ.

    So this but will only show up:
    - your drive is a Samsung 840 EVO (850 aren't affected by the speed decay and didn't get the faulty upgrade)
    - if you have upgraded the firmware to the latest (faulty) version.
    - you run an OS which is actually able to use TRIM+NCQ (Linux and BSD, basically)
    - your OS also follows the standards (asks the drive what is supported and gets the false advertisement of TRIM+NCQ).
    - you actually enable TRIM on the drive.

    remove any one point of this chain and the bug doesn't happen.

    --
    "Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
  53. Re:Btrfs? by sshir · · Score: 1

    Couple of things: first, disk never gets near full because of root reservation. Second - there is implicit trim when you overwrite a block with new data (think about it). So my point still stands. Additionally it is confirmed experimentally - at some point I used a trashy usb stick as the only drive on a 24/7 microserver (with a lot of writes) for over a year with no problems. And you are wrong about reserved blocks - they are not only for bad blocks. Read some reports on Intel enterprise drives.

  54. The thing Windows does by DrYak · · Score: 1

    I have an 850 Pro at home and an 850 EVO at work, and haven't experienced any corruption. I know that Windows uses TRIM. Why am I not seeing any problems?

    You're shielded from the problem because of 2 different things:

    - Samsung 850 aren't as much affected by speed decay as Samsung 840. Thus a firmware fixing the speed problem was only shipped for 840s, not for 850s - and it's that firmware which had the problem. You drive simply didn't get the problematic firmware.

    - That newest firmware falsely advertises that the drive supports TRIM together with NCQ. But the drive actually doesn't.Re-ordering should happen while TRIM is used.
    Linux follows the standards: it asks the drive and only uses the feature that are advertised as supported. Because that specific firmware on that specific drive falsely reports supporting a missing feature, corruption happens.
    Windows simply doesn't support TRIM with NCQ at all. The bug isn't triggered.

    The current fix in linux is to put the drive on a blacklist and mimic Windows behavior by ignoring TRIM+NCQ.

    So: The differences is that Linux uses TRIM+NCQ when instructed by the drive, whereas Windows doesn't. And your drive didn't happen to get the firmware that falsely report this.

    --
    "Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
  55. Indeed by DrYak · · Score: 1

    Windows is doing it wrong {..} When Linux tries to follow the standard and do it right, it gets burned.

    Indeed, that right: Windows doesn't support TRIM+NCQ, whereas Linux does and will enable it if the drive reports it as present.

    the ssd manufacture has 'modified' their firmware to work around it. {...} and the ssd manufacture has 'modified' their firmware to work around it.

    In this case it's purely accidental. Samsung issued a firmware upgrade for some Samsung SSD to fix a problem causing a decay of speed as data ages on the SSD. That new firmware happens to falsely report support for TRIM+NCQ whereas it doesn't actually support it.
    It's a bug left in a new firmware fix, not a tweak intentionally designed to work around quirks and bugs in windows.

    The bug doesn't trigger in Windows because windows doesn't support the feature. Linux (and BSD ?) do and are affected.

    --
    "Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
  56. TRIM+NCQ by DrYak · · Score: 1

    Except that's irrelevant, the guys didn't use queued TRIM either. It says in the article itself that they used non-queued TRIM.

    They more precisley said :

    The TRIM on our drives is un-queued

    Which is true.

    Except that, recent firmware fixes from Samsung (you know, the whole "speed decay on aging data" fiasco) had suddenly started to falsely report support for TRIM+NCQ.

    So it might be possible that unkowningly to them, their Linux installation has suddenly started to issue queued TRIMs, even if the drive actually don't support them, because it trusts what the firmware told to do.

    --
    "Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
  57. Re:Is there a site maintaining a list of "bad" SSD by bobaferret · · Score: 1

    We have Crucial/Micron SSD's in RAID 10 configurations. We of course by them in batch. There's nothing like watching 16 of them all go "bad" at the same time, and not having a clue WTF is going on. Fixed via firmware, but glorious hell, it made my heart sink watching every drive just die in a 20 second window. Randomly and repeatedly over a period of a couple weeks. They all work like a charm now...

  58. Re:Is there a site maintaining a list of "bad" SSD by Coren22 · · Score: 1

    The problem with ReiserFS is you never know when it will kill your drive...

    Bad joke...I know...I'll show myself out.

    --
    APK likes to ask for responses to the same things over and over. Maybe he just likes the responses?
  59. Re:Is there a site maintaining a list of "bad" SSD by Coren22 · · Score: 1

    I assume from that comment you have never actually used a SSD. .5% is a considerable exaduration. It is more like 90%; the drives slow to a crawl until you format them if there is no TRIM support.

    --
    APK likes to ask for responses to the same things over and over. Maybe he just likes the responses?
  60. Re:Is there a site maintaining a list of "bad" SSD by Rich0 · · Score: 1

    There is are two easy solutions to Ext4 vs. SSD problems. The first is ReiserFS which is still eminently usable on Gentoo. The second is UFS which is available on the BSD's.

    If the problem is that the drive doesn't follow the spec for TRIM, I'd rather just disable TRIM than try to keep using it with a different filesystem. That seems a bit like playing Russian Roulette. Are you really that sure that ReiserFS won't have the same problem (unless it just doesn't use TRIM anyway, in which case it is no better than ext4 without TRIM).

  61. Re:Is there a site maintaining a list of "bad" SSD by Rich0 · · Score: 1

    how is f2fs now-a-days?

    No idea in general, but I'd think that a log-based filesystem would be fairly immune to this kind of nonsense since it would only issue TRIMs very rarely, and then only for huge areas of the disk at a time. They don't overwrite random blocks in-place constantly.

  62. Re:Btrfs? by Rich0 · · Score: 1

    Couple of things: first, disk never gets near full because of root reservation. Second - there is implicit trim when you overwrite a block with new data (think about it). So my point still stands.

    He never claimed the drive got full. He said that the issue occurs when you've written a drive's worth of data. You can write a drive's worth of data without filling up even 1% of the drive, if you just overwrite one logical block in-place repeatedly.

    Of course the drive erases a block when you overwrite it. The whole point of trim is that it improves performance when this is done. If you overwrite a 512-byte block that isn't trimmed the drive has to erase the surrounding 4K worth of blocks, and then rewrite the previous data back along with your 512-bytes worth of new data. Then if you write to the next 512-byte block 10min later it repeats the process. For wear-leveling it might move blocks around, but you still have the issue in some form.

    You only can get away with the "implicit trim" strategy completely if you only write in multiples of the SSD erase block size, aligned to SSD erase block boundaries, and the drive actually is designed to let that happen.

    Additionally it is confirmed experimentally - at some point I used a trashy usb stick as the only drive on a 24/7 microserver (with a lot of writes) for over a year with no problems.

    Just what problems would you expect to see? Not using TRIM doesn't cause failures. It can result in premature wear, and lower performance. It doesn't make the drive magically fail long before it should, and unless you did some kind of comparative benchmark you might not notice the performance drop.

  63. Re:Mentioned in a bad way by the Linux kernal? by Gallomimia · · Score: 1

    What's more, windows will allow you to get the same amount of work done with a legit CPU as with a dead rat in that slot.

    --
    Sadly, a Libertarian cannot force his views on another, and freedom cannot spread as does the cancer known as religion.
  64. Re:Is there a site maintaining a list of "bad" SSD by TCM · · Score: 1

    This is about queued TRIM vs. just TRIM, not TRIM vs. no TRIM at all.

    --
    Of course it runs NetBSD. BTC: 1NT7QvbetmANwaMzhpVL6