Announcement

Collapse
No announcement yet.

Linux 5.1 Hit By A Data Loss Bug Due To Overly Aggressive FSTRIM

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Linux 5.1 Hit By A Data Loss Bug Due To Overly Aggressive FSTRIM

    Phoronix: Linux 5.1 Hit By A Data Loss Bug Due To Overly Aggressive FSTRIM

    As a forewarning to those using LVM, dm-crypt, and Samsung solid-state drives, this combination in some manner(s) may lead to data corruption if using the Linux 5.1 kernel...

    http://www.phoronix.com/scan.php?pag...5.1-FSTRIM-Bug

  • starshipeleven
    replied
    Originally posted by birdie View Post
    Are GHK and other kernel developers smart pathetic trolls as well? They insist that kernel releases found on kernel.org are stable.
    Stable != 100% bug free

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by mac_Badger View Post
    and what would be clear reasons for not using them
    Firmware bugs.
    From the distant past https://www.anandtech.com/show/6503/...0-pro-failures
    to more recent times
    https://www.theregister.co.uk/2015/0...rked_firmware/
    https://www.techpowerup.com/239265/l...es-instability

    Also, almost every Samsung SSD has some features blacklisted in the kernel, and until you use a kernel that blacklists the buggy features your data is at risk.

    Can I point out that this is very likely a Samsung firmware bug too?

    top ranked SSDs on the market on a level plane with Intel
    You mean strong advertising.

    they're fantastic drives and have served me extremely well for 3 years now with 100% health remaining, something I don't hear commonly with WD, Kingston, Crucial and Kingmax owners, but of course mmv on any product.
    That just means you aren't using them as much as others.

    SSDs from other brands don't have dramatically different (better or worse) write endurance. All modern SSDs will last decades of daily 10GB writes.

    Leave a comment:


  • mac_Badger
    replied
    Originally posted by starshipeleven View Post

    Why are you even still using Samsung drives at all.
    and what would be clear reasons for not using them, considering that they're the top ranked SSDs on the market on a level plane with Intel and are reasonably priced for their quality? Apart from no native updating or FOSS software monitoring solution (which I doubt most others have too), they're fantastic drives and have served me extremely well for 3 years now with 100% health remaining, something I don't hear commonly with WD, Kingston, Crucial and Kingmax owners, but of course mmv on any product.

    Leave a comment:


  • howaboutsynergy
    replied
    chances are you only get bit by this if your drive actually returns zeroes for the trimmed portions instead of just what was there originally anyway(ie. acting like an HDD),
    ie. sudo hdparm -I -- "/dev/sda" | grep -F 'Deterministic read ZEROs after TRIM'
    (that's uppercase i)

    to my knowledge,

    drives that don't:
    Kingston KINGSTON SA400S37240G firmware SBFK71B1, Samsung SSD 840 EVO 1TB firmware EXT0BB6Q or EXT0DB6Q

    drives that do:
    INTEL SSDSA2M080G2GC firmware 2CV102M3

    Leave a comment:


  • gbcox
    replied
    Originally posted by debianxfce View Post
    https://freedesktop.org/wiki/Softwar...Optimizations/

    16. Don't use debug kernels. Debug kernels are slow. Fedora exclusively uses debug kernels during the development phase of each release. If you care about boot performance, either recompile these kernels with debugging turned off or wait for the final distribution release. It's a drastic difference.
    https://koji.fedoraproject.org/koji/...uildID=1270326 has debug enabled builds available, but you have to specifically download and install them. They contain "debug" in the filename. Development goes into rawhide, which is currently FC31.

    For more about the Fedora Kernel Debug Strategy: https://fedoraproject.org/wiki/KernelDebugStrategy

    Leave a comment:


  • Chugworth
    replied
    Originally posted by Weasel View Post
    Except it doesn't.

    The reason it's slower is because, when you write to the same block, it has to erase the block first, then write it. TRIM just places the "erase the block" way ahead of the actual write, so all it will have to do is write the block, no erase needed. That doesn't mean that erase doesn't happen. It still does, but when you run TRIM on it, not when you write the block. Hence the write itself is faster. The total amount of operations is the same though.
    No, that's not correct. You're right about the garbage collection, but garbage collection also occurs when writing to a block that's not empty (thus the increased write operations). Here's a pretty good explanation of why that happens:

    Flash memory is divided into blocks, which is further divided in pages. Data can be written directly into an empty page, but only whole blocks can be erased. Therefore, to reclaim the space taken up by invalid data, all the valid data from one block must be first copied and written into the empty pages of a new block. Only then can the invalid data in the original block be erased, making it ready for new valid data to be written.
    http://www.thessdreview.com/daily-ne...an-ssd-primer/

    Leave a comment:


  • birdie
    replied
    Originally posted by Wojcian View Post

    If you were little smarter pathetic troll, you will realize to use stable distributions when you want stability. Show me winblos.kernel.org or shut up moron.
    Are GHK and other kernel developers smart pathetic trolls as well? They insist that kernel releases found on kernel.org are stable. You could troll a tad smarter but with so little gray matter in your skull it's nigh impossible.

    Leave a comment:


  • starshipeleven
    replied
    Originally posted by shmerl View Post

    How do you update firmware for Samsung drives on Linux?
    Why are you even still using Samsung drives at all.

    Leave a comment:


  • Weasel
    replied
    Originally posted by Chugworth View Post
    If TRIM was not run on a block before new data is written to it, that actually causes more writes to occur internally in the SSD.
    Except it doesn't.

    The reason it's slower is because, when you write to the same block, it has to erase the block first, then write it. TRIM just places the "erase the block" way ahead of the actual write, so all it will have to do is write the block, no erase needed. That doesn't mean that erase doesn't happen. It still does, but when you run TRIM on it, not when you write the block. Hence the write itself is faster. The total amount of operations is the same though.

    The real reason it reduces writes is due to write amplification and garbage collection. The SSD's GC will move around blocks for wear leveling. This includes "deleted" blocks that were not marked as deleted by TRIM, so when it moves those blocks pointlessly, it causes some extra writes.

    This is fairly negligible, however, definitely not worth the risk of data loss. Honestly, if you don't care about write performance that much but care about your data, just don't use TRIM. I'd say safety of your data is worth more than 1% more SSD life, even if we assume it will die from writes (which is unlikely unless you write more than 20 GB every single day and have a small SSD).

    Leave a comment:

Working...
X