| Message ID | 20220204125750.1771303-1-zboszor@pr.hu |
|---|---|
| State | New |
| Headers | show |
| Series | libata: add horkage for M88V29 | expand |
On 2/4/22 21:57, zboszor@pr.hu wrote: > From: Zoltán Böszörményi <zboszor@gmail.com> > > This device is a CF card, or possibly an SSD in CF form factor. > It supports NCQ and high speed DMA. > > While it also advertises TRIM support, I/O errors are reported > when the discard mount option fstrim is used. TRIM also fails > when disabling NCQ and not just as an NCQ command. > > TRIM must be disabled for this device. > > Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com> > --- > drivers/ata/libata-core.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c > index 67f88027680a..4a7f58fcc411 100644 > --- a/drivers/ata/libata-core.c > +++ b/drivers/ata/libata-core.c > @@ -4028,6 +4028,7 @@ static const struct ata_blacklist_entry ata_device_blacklist [] = { > > /* devices that don't properly handle TRIM commands */ > { "SuperSSpeed S238*", NULL, ATA_HORKAGE_NOTRIM, }, > + { "M88V29*", NULL, ATA_HORKAGE_NOTRIM, }, > > /* > * As defined, the DRAT (Deterministic Read After Trim) and RZAT Applied to for-5.17-fixes. Thanks !
2022. 02. 08. 9:07 keltezéssel, Damien Le Moal írta: > On 2/4/22 21:57, zboszor@pr.hu wrote: >> From: Zoltán Böszörményi <zboszor@gmail.com> >> >> This device is a CF card, or possibly an SSD in CF form factor. >> It supports NCQ and high speed DMA. >> >> While it also advertises TRIM support, I/O errors are reported >> when the discard mount option fstrim is used. TRIM also fails >> when disabling NCQ and not just as an NCQ command. >> >> TRIM must be disabled for this device. >> >> Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com> >> --- >> drivers/ata/libata-core.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c >> index 67f88027680a..4a7f58fcc411 100644 >> --- a/drivers/ata/libata-core.c >> +++ b/drivers/ata/libata-core.c >> @@ -4028,6 +4028,7 @@ static const struct ata_blacklist_entry ata_device_blacklist [] = { >> >> /* devices that don't properly handle TRIM commands */ >> { "SuperSSpeed S238*", NULL, ATA_HORKAGE_NOTRIM, }, >> + { "M88V29*", NULL, ATA_HORKAGE_NOTRIM, }, >> >> /* >> * As defined, the DRAT (Deterministic Read After Trim) and RZAT > Applied to for-5.17-fixes. Thanks ! Thank you. However, I have second thoughts about this patch. The device advertises this: # hdparm -iI /dev/sda ... Enabled Supported * Data Set Management TRIM supported (limit 1 block) ... but the I/O failures always reported higher number of blocks, IIRC the attempted number of block was 8 or so. Can the kernel limit or split TRIM commands according to the advertised limit? If not (or not yet) then the quirk is good for now. Best regards, Zoltán Böszörményi
2022. 06. 23. 9:47 keltezéssel, Böszörményi Zoltán írta: > 2022. 02. 08. 9:07 keltezéssel, Damien Le Moal írta: >> On 2/4/22 21:57, zboszor@pr.hu wrote: >>> From: Zoltán Böszörményi <zboszor@gmail.com> >>> >>> This device is a CF card, or possibly an SSD in CF form factor. >>> It supports NCQ and high speed DMA. >>> >>> While it also advertises TRIM support, I/O errors are reported >>> when the discard mount option fstrim is used. TRIM also fails >>> when disabling NCQ and not just as an NCQ command. >>> >>> TRIM must be disabled for this device. >>> >>> Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com> >>> --- >>> drivers/ata/libata-core.c | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c >>> index 67f88027680a..4a7f58fcc411 100644 >>> --- a/drivers/ata/libata-core.c >>> +++ b/drivers/ata/libata-core.c >>> @@ -4028,6 +4028,7 @@ static const struct ata_blacklist_entry ata_device_blacklist [] = { >>> /* devices that don't properly handle TRIM commands */ >>> { "SuperSSpeed S238*", NULL, ATA_HORKAGE_NOTRIM, }, >>> + { "M88V29*", NULL, ATA_HORKAGE_NOTRIM, }, >>> /* >>> * As defined, the DRAT (Deterministic Read After Trim) and RZAT >> Applied to for-5.17-fixes. Thanks ! > > Thank you. However, I have second thoughts about this patch. > The device advertises this: > > # hdparm -iI /dev/sda > ... > Enabled Supported > * Data Set Management TRIM supported (limit 1 block) > ... Here's the complete hdparm output: /dev/sda: Model=M88V29 32GB, FwRev=181019i, SerialNo=20211023AA20A0656011 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs } RawCHS=16383/15/63, TrkSize=0, SectSize=0, ECCbytes=4 BuffType=unknown, BuffSize=unknown, MaxMultSect=1, MultSect=off CurCHS=16383/15/63, CurSects=15481935, LBA=yes, LBAsects=62533296 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120} PIO modes: pio0 pio1 pio2 pio3 pio4 DMA modes: mdma0 mdma1 mdma2 UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5 AdvancedPM=yes: unknown setting Drive conforms to: Unspecified: ATA/ATAPI-5,6,7 * signifies the current active mode CompactFlash ATA device Model Number: M88V29 32GB Serial Number: 20211023AA20A0656011 Firmware Revision: 181019i Standards: Supported: 8 7 6 5 Likely used: 8 Configuration: Logical max current cylinders 16383 16383 heads 15 15 sectors/track 63 63 -- CHS current addressable sectors: 15481935 LBA user addressable sectors: 62533296 LBA48 user addressable sectors: 62533296 Logical/Physical Sector size: 512 bytes device size with M = 1024*1024: 30533 MBytes device size with M = 1000*1000: 32017 MBytes (32 GB) cache/buffer size = unknown Nominal Media Rotation Rate: Solid State Device Capabilities: LBA, IORDY(can be disabled) Standby timer values: spec'd by Vendor, with device specific minimum R/W multiple sector transfer: Max = 1 Current = 0 Advanced power management level: 0 DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5 Cycle time: min=120ns recommended=120ns PIO: pio0 pio1 pio2 pio3 pio4 Cycle time: no flow control=120ns IORDY flow control=120ns Commands/features: Enabled Supported: * SMART feature set Security Mode feature set * Power Management feature set * Look-ahead * WRITE_BUFFER command * READ_BUFFER command * NOP cmd * DOWNLOAD_MICROCODE * CFA feature set * Advanced Power Management feature set * 48-bit Address feature set * Mandatory FLUSH_CACHE * FLUSH_CACHE_EXT * SMART error logging * SMART self-test * General Purpose Logging feature set * WRITE_{DMA|MULTIPLE}_FUA_EXT * {READ,WRITE}_DMA_EXT_GPL commands * DOWNLOAD MICROCODE DMA command * Data Set Management TRIM supported (limit 1 block) * Deterministic read data after TRIM CFA max advanced io_udma cycle time: 80ns CFA max advanced mem_udma cycle time: 80ns * CFA advanced modes: pio5 pio6 mdma3 mdma4 io_udma4 io_udma5 io_udma6 io_udma7 io_udma8 *io_udma9 mem_udma4 mem_udma5 mem_udma6 mem_udma7 mem_udma8 *mem_udma9 CFA Power Level 1 not supported (max 100mA) Security: supported not enabled not locked frozen not expired: security count supported: enhanced erase 4min for SECURITY ERASE UNIT. 4min for ENHANCED SECURITY ERASE UNIT. HW reset results: CBLID- above Vih Device num = 0 Checksum: correct > > but the I/O failures always reported higher number of blocks, > IIRC the attempted number of block was 8 or so. > > Can the kernel limit or split TRIM commands according to the > advertised limit? If not (or not yet) then the quirk is good for now. > > Best regards, > Zoltán Böszörményi >
On 6/23/22 16:47, Böszörményi Zoltán wrote: > 2022. 02. 08. 9:07 keltezéssel, Damien Le Moal írta: >> On 2/4/22 21:57, zboszor@pr.hu wrote: >>> From: Zoltán Böszörményi <zboszor@gmail.com> >>> >>> This device is a CF card, or possibly an SSD in CF form factor. >>> It supports NCQ and high speed DMA. >>> >>> While it also advertises TRIM support, I/O errors are reported >>> when the discard mount option fstrim is used. TRIM also fails >>> when disabling NCQ and not just as an NCQ command. >>> >>> TRIM must be disabled for this device. >>> >>> Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com> >>> --- >>> drivers/ata/libata-core.c | 1 + >>> 1 file changed, 1 insertion(+) >>> >>> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c >>> index 67f88027680a..4a7f58fcc411 100644 >>> --- a/drivers/ata/libata-core.c >>> +++ b/drivers/ata/libata-core.c >>> @@ -4028,6 +4028,7 @@ static const struct ata_blacklist_entry ata_device_blacklist [] = { >>> >>> /* devices that don't properly handle TRIM commands */ >>> { "SuperSSpeed S238*", NULL, ATA_HORKAGE_NOTRIM, }, >>> + { "M88V29*", NULL, ATA_HORKAGE_NOTRIM, }, >>> >>> /* >>> * As defined, the DRAT (Deterministic Read After Trim) and RZAT >> Applied to for-5.17-fixes. Thanks ! > > Thank you. However, I have second thoughts about this patch. > The device advertises this: > > # hdparm -iI /dev/sda > ... > Enabled Supported > * Data Set Management TRIM supported (limit 1 block) > ... > > but the I/O failures always reported higher number of blocks, > IIRC the attempted number of block was 8 or so. > > Can the kernel limit or split TRIM commands according to the > advertised limit? If not (or not yet) then the quirk is good for now. Yes, the kernel does that. See the sysfs queue attributes discard_max_bytes and discard_max_hw_bytes. What are the values for your device ? I think that the "limit 1 block" indicated by hdparm is simply to say that the DSM command (to trim the device) accept only at most a 1 block (512 B) list of sectors to trim. That is not the actual trim limit for each sector range in that list. > > Best regards, > Zoltán Böszörményi >
2022. 06. 23. 10:22 keltezéssel, Damien Le Moal írta: > On 6/23/22 16:47, Böszörményi Zoltán wrote: >> 2022. 02. 08. 9:07 keltezéssel, Damien Le Moal írta: >>> On 2/4/22 21:57, zboszor@pr.hu wrote: >>>> From: Zoltán Böszörményi <zboszor@gmail.com> >>>> >>>> This device is a CF card, or possibly an SSD in CF form factor. >>>> It supports NCQ and high speed DMA. >>>> >>>> While it also advertises TRIM support, I/O errors are reported >>>> when the discard mount option fstrim is used. TRIM also fails >>>> when disabling NCQ and not just as an NCQ command. >>>> >>>> TRIM must be disabled for this device. >>>> >>>> Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com> >>>> --- >>>> drivers/ata/libata-core.c | 1 + >>>> 1 file changed, 1 insertion(+) >>>> >>>> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c >>>> index 67f88027680a..4a7f58fcc411 100644 >>>> --- a/drivers/ata/libata-core.c >>>> +++ b/drivers/ata/libata-core.c >>>> @@ -4028,6 +4028,7 @@ static const struct ata_blacklist_entry ata_device_blacklist [] = { >>>> >>>> /* devices that don't properly handle TRIM commands */ >>>> { "SuperSSpeed S238*", NULL, ATA_HORKAGE_NOTRIM, }, >>>> + { "M88V29*", NULL, ATA_HORKAGE_NOTRIM, }, >>>> >>>> /* >>>> * As defined, the DRAT (Deterministic Read After Trim) and RZAT >>> Applied to for-5.17-fixes. Thanks ! >> Thank you. However, I have second thoughts about this patch. >> The device advertises this: >> >> # hdparm -iI /dev/sda >> ... >> Enabled Supported >> * Data Set Management TRIM supported (limit 1 block) >> ... >> >> but the I/O failures always reported higher number of blocks, >> IIRC the attempted number of block was 8 or so. >> >> Can the kernel limit or split TRIM commands according to the >> advertised limit? If not (or not yet) then the quirk is good for now. > Yes, the kernel does that. See the sysfs queue attributes > discard_max_bytes and discard_max_hw_bytes. What are the values for your > device ? I think that the "limit 1 block" indicated by hdparm is simply to > say that the DSM command (to trim the device) accept only at most a 1 > block (512 B) list of sectors to trim. That is not the actual trim limit > for each sector range in that list. With the quirk in effect (TRIM disabled) I have these: [root@chef queue]# pwd /sys/block/sda/queue [root@chef queue]# cat discard_granularity 0 [root@chef queue]# cat discard_max_bytes 0 [root@chef queue]# cat discard_max_hw_bytes 0 > >> Best regards, >> Zoltán Böszörményi >> >
2022. 06. 23. 10:38 keltezéssel, Böszörményi Zoltán írta: > 2022. 06. 23. 10:22 keltezéssel, Damien Le Moal írta: >> On 6/23/22 16:47, Böszörményi Zoltán wrote: >>> 2022. 02. 08. 9:07 keltezéssel, Damien Le Moal írta: >>>> On 2/4/22 21:57, zboszor@pr.hu wrote: >>>>> From: Zoltán Böszörményi <zboszor@gmail.com> >>>>> >>>>> This device is a CF card, or possibly an SSD in CF form factor. >>>>> It supports NCQ and high speed DMA. >>>>> >>>>> While it also advertises TRIM support, I/O errors are reported >>>>> when the discard mount option fstrim is used. TRIM also fails >>>>> when disabling NCQ and not just as an NCQ command. >>>>> >>>>> TRIM must be disabled for this device. >>>>> >>>>> Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com> >>>>> --- >>>>> drivers/ata/libata-core.c | 1 + >>>>> 1 file changed, 1 insertion(+) >>>>> >>>>> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c >>>>> index 67f88027680a..4a7f58fcc411 100644 >>>>> --- a/drivers/ata/libata-core.c >>>>> +++ b/drivers/ata/libata-core.c >>>>> @@ -4028,6 +4028,7 @@ static const struct ata_blacklist_entry ata_device_blacklist >>>>> [] = { >>>>> /* devices that don't properly handle TRIM commands */ >>>>> { "SuperSSpeed S238*", NULL, ATA_HORKAGE_NOTRIM, }, >>>>> + { "M88V29*", NULL, ATA_HORKAGE_NOTRIM, }, >>>>> /* >>>>> * As defined, the DRAT (Deterministic Read After Trim) and RZAT >>>> Applied to for-5.17-fixes. Thanks ! >>> Thank you. However, I have second thoughts about this patch. >>> The device advertises this: >>> >>> # hdparm -iI /dev/sda >>> ... >>> Enabled Supported >>> * Data Set Management TRIM supported (limit 1 block) >>> ... >>> >>> but the I/O failures always reported higher number of blocks, >>> IIRC the attempted number of block was 8 or so. >>> >>> Can the kernel limit or split TRIM commands according to the >>> advertised limit? If not (or not yet) then the quirk is good for now. >> Yes, the kernel does that. See the sysfs queue attributes >> discard_max_bytes and discard_max_hw_bytes. What are the values for your >> device ? I think that the "limit 1 block" indicated by hdparm is simply to >> say that the DSM command (to trim the device) accept only at most a 1 >> block (512 B) list of sectors to trim. That is not the actual trim limit >> for each sector range in that list. > > With the quirk in effect (TRIM disabled) I have these: > > [root@chef queue]# pwd > /sys/block/sda/queue > [root@chef queue]# cat discard_granularity > 0 > [root@chef queue]# cat discard_max_bytes > 0 > [root@chef queue]# cat discard_max_hw_bytes > 0 And also this, which seems to match the sector limit: [root@chef queue]# cat max_discard_segments 1 > >> >>> Best regards, >>> Zoltán Böszörményi >>> >> >
On 6/23/22 17:38, Böszörményi Zoltán wrote: > 2022. 06. 23. 10:22 keltezéssel, Damien Le Moal írta: >> On 6/23/22 16:47, Böszörményi Zoltán wrote: >>> 2022. 02. 08. 9:07 keltezéssel, Damien Le Moal írta: >>>> On 2/4/22 21:57, zboszor@pr.hu wrote: >>>>> From: Zoltán Böszörményi <zboszor@gmail.com> >>>>> >>>>> This device is a CF card, or possibly an SSD in CF form factor. >>>>> It supports NCQ and high speed DMA. >>>>> >>>>> While it also advertises TRIM support, I/O errors are reported >>>>> when the discard mount option fstrim is used. TRIM also fails >>>>> when disabling NCQ and not just as an NCQ command. >>>>> >>>>> TRIM must be disabled for this device. >>>>> >>>>> Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com> >>>>> --- >>>>> drivers/ata/libata-core.c | 1 + >>>>> 1 file changed, 1 insertion(+) >>>>> >>>>> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c >>>>> index 67f88027680a..4a7f58fcc411 100644 >>>>> --- a/drivers/ata/libata-core.c >>>>> +++ b/drivers/ata/libata-core.c >>>>> @@ -4028,6 +4028,7 @@ static const struct ata_blacklist_entry ata_device_blacklist [] = { >>>>> >>>>> /* devices that don't properly handle TRIM commands */ >>>>> { "SuperSSpeed S238*", NULL, ATA_HORKAGE_NOTRIM, }, >>>>> + { "M88V29*", NULL, ATA_HORKAGE_NOTRIM, }, >>>>> >>>>> /* >>>>> * As defined, the DRAT (Deterministic Read After Trim) and RZAT >>>> Applied to for-5.17-fixes. Thanks ! >>> Thank you. However, I have second thoughts about this patch. >>> The device advertises this: >>> >>> # hdparm -iI /dev/sda >>> ... >>> Enabled Supported >>> * Data Set Management TRIM supported (limit 1 block) >>> ... >>> >>> but the I/O failures always reported higher number of blocks, >>> IIRC the attempted number of block was 8 or so. >>> >>> Can the kernel limit or split TRIM commands according to the >>> advertised limit? If not (or not yet) then the quirk is good for now. >> Yes, the kernel does that. See the sysfs queue attributes >> discard_max_bytes and discard_max_hw_bytes. What are the values for your >> device ? I think that the "limit 1 block" indicated by hdparm is simply to >> say that the DSM command (to trim the device) accept only at most a 1 >> block (512 B) list of sectors to trim. That is not the actual trim limit >> for each sector range in that list. > > With the quirk in effect (TRIM disabled) I have these: > > [root@chef queue]# pwd > /sys/block/sda/queue > [root@chef queue]# cat discard_granularity > 0 > [root@chef queue]# cat discard_max_bytes > 0 > [root@chef queue]# cat discard_max_hw_bytes > 0 Yes, expected. What are the values without the quirk applied ? With 5.19, you can use libata.force to disable/enable it. See Documentation/admin-guide/kernel-parameters.txt for details. You could try disabling DSM TRIM (queued trim) and see if the non-ncq trim work.
2022. 06. 23. 10:46 keltezéssel, Damien Le Moal írta: > On 6/23/22 17:38, Böszörményi Zoltán wrote: >> 2022. 06. 23. 10:22 keltezéssel, Damien Le Moal írta: >>> On 6/23/22 16:47, Böszörményi Zoltán wrote: >>>> 2022. 02. 08. 9:07 keltezéssel, Damien Le Moal írta: >>>>> On 2/4/22 21:57, zboszor@pr.hu wrote: >>>>>> From: Zoltán Böszörményi <zboszor@gmail.com> >>>>>> >>>>>> This device is a CF card, or possibly an SSD in CF form factor. >>>>>> It supports NCQ and high speed DMA. >>>>>> >>>>>> While it also advertises TRIM support, I/O errors are reported >>>>>> when the discard mount option fstrim is used. TRIM also fails >>>>>> when disabling NCQ and not just as an NCQ command. >>>>>> >>>>>> TRIM must be disabled for this device. >>>>>> >>>>>> Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com> >>>>>> --- >>>>>> drivers/ata/libata-core.c | 1 + >>>>>> 1 file changed, 1 insertion(+) >>>>>> >>>>>> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c >>>>>> index 67f88027680a..4a7f58fcc411 100644 >>>>>> --- a/drivers/ata/libata-core.c >>>>>> +++ b/drivers/ata/libata-core.c >>>>>> @@ -4028,6 +4028,7 @@ static const struct ata_blacklist_entry ata_device_blacklist [] = { >>>>>> >>>>>> /* devices that don't properly handle TRIM commands */ >>>>>> { "SuperSSpeed S238*", NULL, ATA_HORKAGE_NOTRIM, }, >>>>>> + { "M88V29*", NULL, ATA_HORKAGE_NOTRIM, }, >>>>>> >>>>>> /* >>>>>> * As defined, the DRAT (Deterministic Read After Trim) and RZAT >>>>> Applied to for-5.17-fixes. Thanks ! >>>> Thank you. However, I have second thoughts about this patch. >>>> The device advertises this: >>>> >>>> # hdparm -iI /dev/sda >>>> ... >>>> Enabled Supported >>>> * Data Set Management TRIM supported (limit 1 block) >>>> ... >>>> >>>> but the I/O failures always reported higher number of blocks, >>>> IIRC the attempted number of block was 8 or so. >>>> >>>> Can the kernel limit or split TRIM commands according to the >>>> advertised limit? If not (or not yet) then the quirk is good for now. >>> Yes, the kernel does that. See the sysfs queue attributes >>> discard_max_bytes and discard_max_hw_bytes. What are the values for your >>> device ? I think that the "limit 1 block" indicated by hdparm is simply to >>> say that the DSM command (to trim the device) accept only at most a 1 >>> block (512 B) list of sectors to trim. That is not the actual trim limit >>> for each sector range in that list. >> With the quirk in effect (TRIM disabled) I have these: >> >> [root@chef queue]# pwd >> /sys/block/sda/queue >> [root@chef queue]# cat discard_granularity >> 0 >> [root@chef queue]# cat discard_max_bytes >> 0 >> [root@chef queue]# cat discard_max_hw_bytes >> 0 > Yes, expected. What are the values without the quirk applied ? I built 5.18.6 with removing the quirk. [root@chef queue]# pwd /sys/block/sda/queue/ [root@chef queue]# cat discard_granularity 512 [root@chef queue]# cat discard_max_bytes 2147450880 [root@chef queue]# cat discard_max_hw_bytes 2147450880 [root@chef queue]# cat max_discard_segments 1 > With 5.19, you can use libata.force to disable/enable it. See > Documentation/admin-guide/kernel-parameters.txt for details. > You could try disabling DSM TRIM (queued trim) and see if the non-ncq trim > work. >
On 6/23/22 18:32, Böszörményi Zoltán wrote: > 2022. 06. 23. 10:46 keltezéssel, Damien Le Moal írta: >> On 6/23/22 17:38, Böszörményi Zoltán wrote: >>> 2022. 06. 23. 10:22 keltezéssel, Damien Le Moal írta: >>>> On 6/23/22 16:47, Böszörményi Zoltán wrote: >>>>> 2022. 02. 08. 9:07 keltezéssel, Damien Le Moal írta: >>>>>> On 2/4/22 21:57, zboszor@pr.hu wrote: >>>>>>> From: Zoltán Böszörményi <zboszor@gmail.com> >>>>>>> >>>>>>> This device is a CF card, or possibly an SSD in CF form factor. >>>>>>> It supports NCQ and high speed DMA. >>>>>>> >>>>>>> While it also advertises TRIM support, I/O errors are reported >>>>>>> when the discard mount option fstrim is used. TRIM also fails >>>>>>> when disabling NCQ and not just as an NCQ command. >>>>>>> >>>>>>> TRIM must be disabled for this device. >>>>>>> >>>>>>> Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com> >>>>>>> --- >>>>>>> drivers/ata/libata-core.c | 1 + >>>>>>> 1 file changed, 1 insertion(+) >>>>>>> >>>>>>> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c >>>>>>> index 67f88027680a..4a7f58fcc411 100644 >>>>>>> --- a/drivers/ata/libata-core.c >>>>>>> +++ b/drivers/ata/libata-core.c >>>>>>> @@ -4028,6 +4028,7 @@ static const struct ata_blacklist_entry ata_device_blacklist [] = { >>>>>>> >>>>>>> /* devices that don't properly handle TRIM commands */ >>>>>>> { "SuperSSpeed S238*", NULL, ATA_HORKAGE_NOTRIM, }, >>>>>>> + { "M88V29*", NULL, ATA_HORKAGE_NOTRIM, }, >>>>>>> >>>>>>> /* >>>>>>> * As defined, the DRAT (Deterministic Read After Trim) and RZAT >>>>>> Applied to for-5.17-fixes. Thanks ! >>>>> Thank you. However, I have second thoughts about this patch. >>>>> The device advertises this: >>>>> >>>>> # hdparm -iI /dev/sda >>>>> ... >>>>> Enabled Supported >>>>> * Data Set Management TRIM supported (limit 1 block) >>>>> ... >>>>> >>>>> but the I/O failures always reported higher number of blocks, >>>>> IIRC the attempted number of block was 8 or so. >>>>> >>>>> Can the kernel limit or split TRIM commands according to the >>>>> advertised limit? If not (or not yet) then the quirk is good for now. >>>> Yes, the kernel does that. See the sysfs queue attributes >>>> discard_max_bytes and discard_max_hw_bytes. What are the values for your >>>> device ? I think that the "limit 1 block" indicated by hdparm is simply to >>>> say that the DSM command (to trim the device) accept only at most a 1 >>>> block (512 B) list of sectors to trim. That is not the actual trim limit >>>> for each sector range in that list. >>> With the quirk in effect (TRIM disabled) I have these: >>> >>> [root@chef queue]# pwd >>> /sys/block/sda/queue >>> [root@chef queue]# cat discard_granularity >>> 0 >>> [root@chef queue]# cat discard_max_bytes >>> 0 >>> [root@chef queue]# cat discard_max_hw_bytes >>> 0 >> Yes, expected. What are the values without the quirk applied ? > > I built 5.18.6 with removing the quirk. > > [root@chef queue]# pwd > /sys/block/sda/queue/ > [root@chef queue]# cat discard_granularity > 512 > [root@chef queue]# cat discard_max_bytes > 2147450880 > [root@chef queue]# cat discard_max_hw_bytes > 2147450880 > [root@chef queue]# cat max_discard_segments > 1 All normal. This is 65535 sectors at most per trim range times 64 ranges at most (64 range in at most 1 512B range list). 65535*512*64=2147450880 So if that is not working, then it means that DSM TRIM are not working correctly on that device. Have you tried disabling NCQ trim ? Use libata.force noncqtrim option. > >> With 5.19, you can use libata.force to disable/enable it. See >> Documentation/admin-guide/kernel-parameters.txt for details. >> You could try disabling DSM TRIM (queued trim) and see if the non-ncq trim >> work. >> >
2022. 06. 23. 11:32 keltezéssel, Böszörményi Zoltán írta: > 2022. 06. 23. 10:46 keltezéssel, Damien Le Moal írta: >> On 6/23/22 17:38, Böszörményi Zoltán wrote: >>> 2022. 06. 23. 10:22 keltezéssel, Damien Le Moal írta: >>>> On 6/23/22 16:47, Böszörményi Zoltán wrote: >>>>> 2022. 02. 08. 9:07 keltezéssel, Damien Le Moal írta: >>>>>> On 2/4/22 21:57, zboszor@pr.hu wrote: >>>>>>> From: Zoltán Böszörményi <zboszor@gmail.com> >>>>>>> >>>>>>> This device is a CF card, or possibly an SSD in CF form factor. >>>>>>> It supports NCQ and high speed DMA. >>>>>>> >>>>>>> While it also advertises TRIM support, I/O errors are reported >>>>>>> when the discard mount option fstrim is used. TRIM also fails >>>>>>> when disabling NCQ and not just as an NCQ command. >>>>>>> >>>>>>> TRIM must be disabled for this device. >>>>>>> >>>>>>> Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com> >>>>>>> --- >>>>>>> drivers/ata/libata-core.c | 1 + >>>>>>> 1 file changed, 1 insertion(+) >>>>>>> >>>>>>> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c >>>>>>> index 67f88027680a..4a7f58fcc411 100644 >>>>>>> --- a/drivers/ata/libata-core.c >>>>>>> +++ b/drivers/ata/libata-core.c >>>>>>> @@ -4028,6 +4028,7 @@ static const struct ata_blacklist_entry ata_device_blacklist >>>>>>> [] = { >>>>>>> /* devices that don't properly handle TRIM commands */ >>>>>>> { "SuperSSpeed S238*", NULL, ATA_HORKAGE_NOTRIM, }, >>>>>>> + { "M88V29*", NULL, ATA_HORKAGE_NOTRIM, }, >>>>>>> /* >>>>>>> * As defined, the DRAT (Deterministic Read After Trim) and RZAT >>>>>> Applied to for-5.17-fixes. Thanks ! >>>>> Thank you. However, I have second thoughts about this patch. >>>>> The device advertises this: >>>>> >>>>> # hdparm -iI /dev/sda >>>>> ... >>>>> Enabled Supported >>>>> * Data Set Management TRIM supported (limit 1 block) >>>>> ... >>>>> >>>>> but the I/O failures always reported higher number of blocks, >>>>> IIRC the attempted number of block was 8 or so. >>>>> >>>>> Can the kernel limit or split TRIM commands according to the >>>>> advertised limit? If not (or not yet) then the quirk is good for now. >>>> Yes, the kernel does that. See the sysfs queue attributes >>>> discard_max_bytes and discard_max_hw_bytes. What are the values for your >>>> device ? I think that the "limit 1 block" indicated by hdparm is simply to >>>> say that the DSM command (to trim the device) accept only at most a 1 >>>> block (512 B) list of sectors to trim. That is not the actual trim limit >>>> for each sector range in that list. >>> With the quirk in effect (TRIM disabled) I have these: >>> >>> [root@chef queue]# pwd >>> /sys/block/sda/queue >>> [root@chef queue]# cat discard_granularity >>> 0 >>> [root@chef queue]# cat discard_max_bytes >>> 0 >>> [root@chef queue]# cat discard_max_hw_bytes >>> 0 >> Yes, expected. What are the values without the quirk applied ? > > I built 5.18.6 with removing the quirk. > > [root@chef queue]# pwd > /sys/block/sda/queue/ > [root@chef queue]# cat discard_granularity > 512 > [root@chef queue]# cat discard_max_bytes > 2147450880 > [root@chef queue]# cat discard_max_hw_bytes > 2147450880 > [root@chef queue]# cat max_discard_segments > 1 "echo 512 >discard_max_hw_bytes" says permission denied. "echo 512 >discard_max_bytes" can be set But with or without libata.force=noncqtrim, running "fstrim /boot" (which is ext4) goes into an infinite loop dumping a lot of I/O errors into dmesg. Interestingly, after setting discard_max_bytes=512, in both cases (with or without libata.force=noncqrtim) running "fstrim /" (which is f2fs) there is no error in dmesg and fstrim returns after a small delay. So I guess TRIM does work but ext4 seems to be misbehaving. FWIW "mount" shows "discard" for the big f2fs partition but it doesn't for ext4 but it's in the default mount option AFAIK. "mount /boot -o remount.discard" doesn't make a difference. the machine dumps a lot of errors into dmesg with "fstrim /boot". > >> With 5.19, you can use libata.force to disable/enable it. See >> Documentation/admin-guide/kernel-parameters.txt for details. >> You could try disabling DSM TRIM (queued trim) and see if the non-ncq trim >> work. >> >
On 6/23/22 19:12, Böszörményi Zoltán wrote: > 2022. 06. 23. 11:32 keltezéssel, Böszörményi Zoltán írta: >> 2022. 06. 23. 10:46 keltezéssel, Damien Le Moal írta: >>> On 6/23/22 17:38, Böszörményi Zoltán wrote: >>>> 2022. 06. 23. 10:22 keltezéssel, Damien Le Moal írta: >>>>> On 6/23/22 16:47, Böszörményi Zoltán wrote: >>>>>> 2022. 02. 08. 9:07 keltezéssel, Damien Le Moal írta: >>>>>>> On 2/4/22 21:57, zboszor@pr.hu wrote: >>>>>>>> From: Zoltán Böszörményi <zboszor@gmail.com> >>>>>>>> >>>>>>>> This device is a CF card, or possibly an SSD in CF form factor. >>>>>>>> It supports NCQ and high speed DMA. >>>>>>>> >>>>>>>> While it also advertises TRIM support, I/O errors are reported >>>>>>>> when the discard mount option fstrim is used. TRIM also fails >>>>>>>> when disabling NCQ and not just as an NCQ command. >>>>>>>> >>>>>>>> TRIM must be disabled for this device. >>>>>>>> >>>>>>>> Signed-off-by: Zoltán Böszörményi <zboszor@gmail.com> >>>>>>>> --- >>>>>>>> drivers/ata/libata-core.c | 1 + >>>>>>>> 1 file changed, 1 insertion(+) >>>>>>>> >>>>>>>> diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c >>>>>>>> index 67f88027680a..4a7f58fcc411 100644 >>>>>>>> --- a/drivers/ata/libata-core.c >>>>>>>> +++ b/drivers/ata/libata-core.c >>>>>>>> @@ -4028,6 +4028,7 @@ static const struct ata_blacklist_entry ata_device_blacklist >>>>>>>> [] = { >>>>>>>> /* devices that don't properly handle TRIM commands */ >>>>>>>> { "SuperSSpeed S238*", NULL, ATA_HORKAGE_NOTRIM, }, >>>>>>>> + { "M88V29*", NULL, ATA_HORKAGE_NOTRIM, }, >>>>>>>> /* >>>>>>>> * As defined, the DRAT (Deterministic Read After Trim) and RZAT >>>>>>> Applied to for-5.17-fixes. Thanks ! >>>>>> Thank you. However, I have second thoughts about this patch. >>>>>> The device advertises this: >>>>>> >>>>>> # hdparm -iI /dev/sda >>>>>> ... >>>>>> Enabled Supported >>>>>> * Data Set Management TRIM supported (limit 1 block) >>>>>> ... >>>>>> >>>>>> but the I/O failures always reported higher number of blocks, >>>>>> IIRC the attempted number of block was 8 or so. >>>>>> >>>>>> Can the kernel limit or split TRIM commands according to the >>>>>> advertised limit? If not (or not yet) then the quirk is good for now. >>>>> Yes, the kernel does that. See the sysfs queue attributes >>>>> discard_max_bytes and discard_max_hw_bytes. What are the values for your >>>>> device ? I think that the "limit 1 block" indicated by hdparm is simply to >>>>> say that the DSM command (to trim the device) accept only at most a 1 >>>>> block (512 B) list of sectors to trim. That is not the actual trim limit >>>>> for each sector range in that list. >>>> With the quirk in effect (TRIM disabled) I have these: >>>> >>>> [root@chef queue]# pwd >>>> /sys/block/sda/queue >>>> [root@chef queue]# cat discard_granularity >>>> 0 >>>> [root@chef queue]# cat discard_max_bytes >>>> 0 >>>> [root@chef queue]# cat discard_max_hw_bytes >>>> 0 >>> Yes, expected. What are the values without the quirk applied ? >> >> I built 5.18.6 with removing the quirk. >> >> [root@chef queue]# pwd >> /sys/block/sda/queue/ >> [root@chef queue]# cat discard_granularity >> 512 >> [root@chef queue]# cat discard_max_bytes >> 2147450880 >> [root@chef queue]# cat discard_max_hw_bytes >> 2147450880 >> [root@chef queue]# cat max_discard_segments >> 1 > > "echo 512 >discard_max_hw_bytes" says permission denied. That is normal. This is a hardware characteristic so this is read only. > "echo 512 >discard_max_bytes" can be set Yes, this is the soft limit that can be used to limit trim command size. > But with or without libata.force=noncqtrim, running > "fstrim /boot" (which is ext4) goes into an infinite loop > dumping a lot of I/O errors into dmesg. > > Interestingly, after setting discard_max_bytes=512, > in both cases (with or without libata.force=noncqrtim) > running "fstrim /" (which is f2fs) there is no error in > dmesg and fstrim returns after a small delay. Which would tend to indicate that the drive only likes single sector trims... > > So I guess TRIM does work but ext4 seems to be misbehaving. I do not think so. The ext4 is going to issue whatever trim request for free blocks it has and the block layer will split these request into at most discard_max_bytes trim commands. You can check this behavior using blktrace. > FWIW "mount" shows "discard" for the big f2fs partition but > it doesn't for ext4 but it's in the default mount option AFAIK. > "mount /boot -o remount.discard" doesn't make a difference. > the machine dumps a lot of errors into dmesg with "fstrim /boot". If you have an empty partition, you could experiment using blkdiscard command to remove the fs.
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c index 67f88027680a..4a7f58fcc411 100644 --- a/drivers/ata/libata-core.c +++ b/drivers/ata/libata-core.c @@ -4028,6 +4028,7 @@ static const struct ata_blacklist_entry ata_device_blacklist [] = { /* devices that don't properly handle TRIM commands */ { "SuperSSpeed S238*", NULL, ATA_HORKAGE_NOTRIM, }, + { "M88V29*", NULL, ATA_HORKAGE_NOTRIM, }, /* * As defined, the DRAT (Deterministic Read After Trim) and RZAT