Hi Martin, On Thu, Jul 16, 2020 at 5:53 AM Martin K. Petersen <martin.petersen@xxxxxxxxxx> wrote: > I really wish we had some more data to work with :( > > Lacking a proper heuristic I guess we don't have any choice to disable > the feature. But that's sad news for the people who currently don't have > problems since their performance will inevitably suffer. It seems like the latest 860 EVO's firmware, RVT24B6Q, is fairly recent. The earliest reference that I could find on Google is this from Jan, 2020: https://smarthdd.com/database/Samsung-SSD-860-EVO-M.2-500GB/RVT24B6Q/ and an Amazon review. Earlier reports seem to be related to ASMedia's chipsets and NCQ quirks. AFAIK, no reports were made in 2018. IIRC the last time we went through this with the 850 series, a bunch of people reported data corruptions, sometimes even filesystem's superblock. Surely, we would have gotten reports of it pretty soon if the drives were indeed faulty. Maybe the latest firmware is to blame? Also, I don't think queued trim is all that crucial to performance imho, at least in the context of Linux. In my experience, regular R/W I/Os were still severely blocked when fstrim is undergoing even with queued trim was in use(which, to my understanding, is exactly what queued trim tried to resolve in the first place?). Probably file-system's implementation is at partial fault too with it sending ERASE commands with too big granularity. I believe f2fs' default discard_granularity of 4KB is what tries to mitigate this. Linux distros are not using the "discard" mount flag by default and defers to periodic fstrim on idle. Android has been doing this since 4.3(2013), and doesn't even use SATA. f2fs avoids this problem entirely by sending ERASE commands only when the drive is idle. All in all, I don't think we should pull out hairs trying to figure out how to do this properly. I'm yet to be convinced that queued trim solves practical performance issues. If we can't figure this out quickly, I agree on blacklisting 860s again. Thanks.
