On 19.09.21 15:27, Hans de Goede wrote:
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.
Is that the "discard" mount option?
I added this to one of the partitions residing on my 860 Evo,
reverted the patch, and it still seems to work just fine.
$ mount | grep sdb
/dev/sdb1 on /mnt/vbox type ext4 (rw,nosuid,nodev,noatime,discard)
Is there another place where discard has to be enabled?
Or is there a way to check that discard is effectively enabled?
Not sure if relevant, but here are a couple of lines from the syslog:
ata4.00: 976773168 sectors, multi 1: LBA48 NCQ (depth 32), AA
[...]
ata4.00: Enabling discard_zeroes_data
Thanks!
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
