From nobody Mon Feb 19 16:40:02 2024 X-Original-To: dev-commits-src-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TdpDQ0JV1z5C8f7; Mon, 19 Feb 2024 16:40:06 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4TdpDP6t0fz4Y29; Mon, 19 Feb 2024 16:40:05 +0000 (UTC) (envelope-from avg@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1708360806; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding:autocrypt:autocrypt; bh=1Cd9c8QPUFolDt8bBq/pC/nTjHuCDTXp+o5blNU7/rk=; b=U+jBF0VxomLcI75uG7/045AQwSJWsmBmFo2rN4k9wG4GN+y9ufENX5q2KoApCrEOHeaYpW xPR2l5iCZC0B15fyHTdgM7yEh2mZL3AcivHgmv8UcxqLCY9tlRrETGUc4iZkGlXwUAdPeU nR9mHCNcjESimstdhZgwIsf3tIaQtwIEwRcjqP8z9qu+dUxbofqBayOri7WeWMMD088whD vkAbe8fDGgA4L9PehwHLwH1JCtmtRwKy68Ej3PYZZqg4BACT3u4vOeHiAhlLBw0V5fhu4j SzxI/vivjd7b/hCSP+k/y5IZ11HtXbK6+aiHKT8ZDW7bV+2khUvCNwVJ+xBneA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1708360806; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding:autocrypt:autocrypt; bh=1Cd9c8QPUFolDt8bBq/pC/nTjHuCDTXp+o5blNU7/rk=; b=smdbHr0+sloJw/bxbnY1szZQrILQPYajVh7aX/DDm0HMjNUW0Ya44Gl4SJrExjpkBGIuhc QtGb6D4R0tDru29KtBGUPUKoWAt+Wge6CbGwffJo0a1DALeXAqlSvKeKTYLzygBTUsAlIy b+VuJRwOqnS4Np4V2m26CeTU9Rjre2hwAukuYNsDyDFkRz9nbB4nqzM8zpHdeV/klVy8A6 VGroe31GE30i3UAMSsVRq6LWnoxntlO1HDKRTRQCzvolcccuSgzZsLi88UNR37j2LC/FK7 EaJ51qTrxpBS28Wl6meUGJBwHlULtTRYxy0TCnpis5j073DLKjhbFzhKsBOuDQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1708360806; a=rsa-sha256; cv=none; b=cM6vpHkUgZEb6T13s4HUZ9DXXVQ68lWIwtY4y6WqdNAfxuAuF3Psicft63MX3RGiHcPaVB IX38RiJF0LF4MaV6Y4+IGM/eDAkPiNSczLr9K0I1AMbFtECrk7BRW9hNCnOWs+j5sz7v2R N8YjyYiIkrcmtikEmgVe+H/sQikNz2VCuTEav23rsioJkVCol7S/nyTAjVTv8049IlLA6J fB7JRDYw02q/xQb3/4ohAgXZr0dYGC1OE3zw19cDgvJrRitDnFmZ6EAJC8jDfZKKbEGqcR 2Eey67WE0NxfZKhHCkynoZGutAkWiR+3BH6e3zQUS4tSvq5cS+WO0WE+lGDJbA== Received: from [192.168.0.88] (unknown [93.188.39.137]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: avg/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4TdpDP0tq3z13Kw; Mon, 19 Feb 2024 16:40:04 +0000 (UTC) (envelope-from avg@freebsd.org) Message-ID: <6a73f7bf-dbe9-416b-a6d0-dded14285574@freebsd.org> Date: Mon, 19 Feb 2024 18:40:02 +0200 List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-all@freebsd.org X-BeenThere: dev-commits-src-all@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla Thunderbird From: Andriy Gapon Subject: Re: git: c01af41c3c8f - main - ata_da: add quirk to disable NCQ TRIM for Samsung 860/870 SSDs Content-Language: en-US To: cglogic , Warner Losh Cc: src-committers , dev-commits-src-all@freebsd.org, dev-commits-src-main@freebsd.org Autocrypt: addr=avg@freebsd.org; keydata= xjMEX1iFDhYJKwYBBAHaRw8BAQdAiu8JG/oLFkVkOAJqJc7Dx5KI/Q6C3SBI20EQm+DXnAvN HkFuZHJpeSBHYXBvbiA8YXZnQEZyZWVCU0Qub3JnPsKWBBMWCAA+FiEEyCHHZM09l0OE3Ir/ 1A1+Gq8+L1EFAl9YhQ4CGwMFCQeEzgAFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AACgkQ1A1+ Gq8+L1Fc0wD/ZjmhHfbCJywZU3aOxXIPjcz73FYEGMvqMCCLAWyLbSABALFL+1ZNrjV3BGjq 889cOYFuboA/Yn3eWezS+tfqYBsGzjgEX1iFDhIKKwYBBAGXVQEFAQEHQL6B20Xi600TrkpG P9fWjl7JtHNxqrHKhX6Kg7kgb4ILAwEIB8J+BBgWCAAmFiEEyCHHZM09l0OE3Ir/1A1+Gq8+ L1EFAl9YhQ4CGwwFCQeEzgAACgkQ1A1+Gq8+L1F3cgEAktp4h+IJUJxL1vn6zMOt//znni/J TanKfQuA8wGXcGkBAKpZJhqMkg+pKk7MGvJhgJ6nCpTZ+rMK6vZVZLUWc3QF Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 19/02/2024 18:06, cglogic wrote: > Hello Warner, > > Thank you for detailed explanation. Looks like it has no sense for me to worry > about disabling NCQ TRIM on that old PC. > > However it would be great to have possibility to apply such hardware bug > workarounds for affected controller/drive pairs only. > Or, at least, have possibility to disable such quirks on per drive basis via > sysctl. I didn't find such a possibility. Yeah, we do not have a way to control ata_da (and scsi_da) quirks via configuration. It would be nice to have it, indeed. Also, perhaps what ADA_Q_NCQ_TRIM_BROKEN could do is prefer a different delete method by default. That way, NCQ_DSM_TRIM option would not disappear completely and it would be possible to set with kern.cam.ada.N.delete_method sysctl. > On Monday, February 19th, 2024 at 5:18 PM, Warner Losh wrote: >> >> >> On Mon, Feb 19, 2024, 4:29 AM cglogic > > wrote: >> >> On Monday, February 19th, 2024 at 1:03 PM, Andriy Gapon >> wrote: >> >> > On 19/02/2024 12:47, cglogic wrote: >> > >> > > Hello Andriy, >> > > >> > > I use ZFS with autotrim enabled on Samsung 860 PRO connected to Intel >> AHCI SATA controller for 9 years without any issue. >> > >> > >> > I think that it was released in 2018? >> >> You are right, it's 9 years old computer, SSD was added later. >> >> > >> > > Can I disable this quirk locally or have I revert the patch to >> continue use NCQ TRIM with this SSD? >> > >> > >> > I don't think that there is a way to disable the quirk, so you'll have >> to revert. >> > Note that ATA TRIM is still enabled, it's only NCQ TRIM that got disabled. >> >> From my understanding ATA TRIM is non-queued TRIM as opposed to NCQ TRIM. >> With only ATA TRIM enabled, drive will have increased latency when large >> amount of files deleted. >> >> However I'm not sure how ZFS handles TRIMs, maybe it groups several TRIMs >> and then sends when drive is idle. >> Another question is how this affects TRIM enabled swap partition. >> >> In general, if I'm correct here, disabling NCQ TRIM should not be an issue >> for desktop usage, except for large git repository updates, etc. >> >> >> In general, it won't matter a ton. Unless you are seeing stalls because of >> read/write I/O waiting behind trims that have to go to the drive one at a >> time, the effects are in the noise. If you are seeing that, though, the >> effects can be quite helpful in terms of latency... assuming the drive is >> cooperative. The benefits of it vary a lot from drive to drive as well. Some >> early drives still serialize the trims, so the latency benefit is not so >> great. Some enterprise drives do trims instantly and keep some internal state >> that is helped a lot by them. But if NCQ trims are unstable, we likely should >> err on the side of disabling. >> >> The errors that Andriy was seeing typically are cable or controller issues. In >> his case, it was a controller issue (apparently, and surprisingly, paired with >> a specific type of drive). Linux has a specific workaround for the pair, which >> is unusual. But there's two issues at play. >> >> The first issue is that these drives should have NCQ Trim turned off, >> according to Linux's commit log. This may be firmware revision based or may >> just be some people are luckier with newer firmware (it's hard to say from the >> mixed reports, but they read more like luck than version for the sampling I >> did). So Andriy's change is good. The second issue, and one I was confused on >> earlier, is that Linux goes a step further and disables NCQ entirely for these >> old controllers for 860 and 870 drives. This isn't too surprising. We have a >> workaround for PMP for these controllers already.... One can disable NCQ >> entirely by setting the tags to 0... Given the specificity of the problem, and >> the age of the controllers, I'm inclined to not implement the Linux workaround >> for this specific pair. -- Andriy Gapon