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;
Subject: Re: [PATCH v5] libata: Add ATA_HORKAGE_NO_NCQ_ON_AMD for Samsung 860
 and 870 SSD.
To:     Tor Vic <torvic9@mailbox.org>,
        "Martin K. Petersen" <martin.petersen@oracle.com>
Cc:     Kate Hsuan <hpa@redhat.com>, Jens Axboe <axboe@kernel.dk>,
        Damien Le Moal <damien.lemoal@wdc.com>,
        linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org
References: <20210901151643.13562-1-hpa@redhat.com>
 <3e26e7a5-0d99-b993-d5ce-aa517e1bf1bb@redhat.com>
 <yq1h7f24y6f.fsf@ca-mkp.ca.oracle.com>
 <238d0841-0f03-928f-5441-89d5c9dcf9b9@redhat.com>
 <cd75fa32-8c4d-664e-5adb-f2f325d3c58e@redhat.com>
 <yq14kb24e97.fsf@ca-mkp.ca.oracle.com>
 <f071dfb3-1aad-003c-00bc-6b7ecf103e91@mailbox.org>
From:   Hans de Goede <hdegoede@redhat.com>
Message-ID: <967d7639-fc31-a209-8c21-ea8ab3718de6@redhat.com>
Date:   Sun, 19 Sep 2021 17:27:05 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <f071dfb3-1aad-003c-00bc-6b7ecf103e91@mailbox.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk

Hi Tor,

On 9/19/21 4:24 PM, Tor Vic wrote:
> Hi,
> 
> I saw that v2 (?) of this patch has made it into stable, which
> is quite reasonable given the number of bug reports.
> Are there any plans to "enhance" this patch once sufficient data
> on controller support/drive combinations has been collected?

ATM there are no plans to limit these quirks, we have bug
reports of queued trims being an issue over all usual chip-vendors
of sata controllers (including more recent AMD models).

Note that unless you have immediate "discard" enabled as an option
on all layers of your storage stack (dmcrypt, device-mapper/raid,
filesystem) then this change will not impact you at all.

Also note that AFAIK all major distros do not enable immediate
discard, instead relying on fstrim runs from a cronjob, which
again means this change will not impact users of those distros.

So chances are that your workload simply never triggered the issue;
and this is the cause of everything always having worked fine for
you.

Regards,

Hans