linux-kernel - Re: [PATCH] ata: Disable queued TRIM for Samsung 860 SSDs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAD14+f1BjqmzGXnt_ha04gD-WpSu7spq93hVMDqnoO60MX3zEg@mail.gmail.com>
Date:   Thu, 16 Jul 2020 07:03:43 +0900
From:   Ju Hyung Park <qkrwngud825@...il.com>
To:     "Martin K. Petersen" <martin.petersen@...cle.com>
Cc:     Simon Arlott <simon@...iron.net>, Jens Axboe <axboe@...nel.dk>,
        linux-ide@...r.kernel.org,
        open list <linux-kernel@...r.kernel.org>,
        Tejun Heo <tj@...nel.org>
Subject: Re: [PATCH] ata: Disable queued TRIM for Samsung 860 SSDs

Hi Martin,

On Thu, Jul 16, 2020 at 5:53 AM Martin K. Petersen
<martin.petersen@...cle.com> 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.