Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <9324ef33-eedd-b965-37e8-b82e06778aab@0882a8b5-c6c3-11e9-b005-00805fc181fe>
 <yq1blkgo6y0.fsf@ca-mkp.ca.oracle.com>
In-Reply-To: <yq1blkgo6y0.fsf@ca-mkp.ca.oracle.com>
From:   Ju Hyung Park <qkrwngud825@gmail.com>
Date:   Thu, 16 Jul 2020 07:03:43 +0900
Message-ID: <CAD14+f1BjqmzGXnt_ha04gD-WpSu7spq93hVMDqnoO60MX3zEg@mail.gmail.com>
Subject: Re: [PATCH] ata: Disable queued TRIM for Samsung 860 SSDs
To:     "Martin K. Petersen" <martin.petersen@oracle.com>
Cc:     Simon Arlott <simon@octiron.net>, Jens Axboe <axboe@kernel.dk>,
        linux-ide@vger.kernel.org,
        open list <linux-kernel@vger.kernel.org>,
        Tejun Heo <tj@kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Hi Martin,

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