Re: SSD - trim fails

On Wed, Nov 2, 2022 at 2:51 PM Wojciech Puchar <wojtek@puchar.net> wrote:

> i have laptop with such SSD drive
>
> ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
> ada0: <SAMSUNG SSD SM841N 2.5 7mm 256GB DXM03D0Q> ACS-2 ATA SATA 3.x
> device
> ada0: Serial Number S1K1NSAF415536
> ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes)
> ada0: Command Queueing enabled
> ada0: 244198MB (500118192 512 byte sectors)
>
>
> everything works very good as long as i don't do trim
>
> when trying trim - for example cleaning all drive with trim -f /dev/ada0
> i'm getting
>
> (ada0:ahcich0:0:0:0): Retrying command, 3 more tries remain
> (ada0:ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MANAGEMENT. ACB: 64 01 00
> 00 00 40 00 00 00 00 00 00
> (ada0:ahcich0:0:0:0): CAM status: Uncorrectable parity/CRC error
> (ada0:ahcich0:0:0:0): Retrying command, 3 more tries remain
> (ada0:ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MANAGEMENT. ACB: 64 01 00
> 00 00 40 00 00 00 00 00 00
> (ada0:ahcich0:0:0:0): CAM status: Uncorrectable parity/CRC error
> (ada0:ahcich0:0:0:0): Retrying command, 3 more tries remain
> (ada0:ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MANAGEMENT. ACB: 64 01 00
> 00 00 40 00 00 00 00 00 00
> (ada0:ahcich0:0:0:0): CAM status: Uncorrectable parity/CRC error
> (ada0:ahcich0:0:0:0): Retrying command, 3 more tries remain
> (ada0:ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MANAGEMENT. ACB: 64 01 00
> 00 00 40 00 00 00 00 00 00
> (ada0:ahcich0:0:0:0): CAM status: Uncorrectable parity/CRC error
> (ada0:ahcich0:0:0:0): Retrying command, 3 more tries remain
> (ada0:ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MANAGEMENT. ACB: 64 01 00
> 00 00 40 00 00 00 00 00 00
> (ada0:ahcich0:0:0:0): CAM status: Uncorrectable parity/CRC error
> (ada0:ahcich0:0:0:0): Retrying command, 3 more tries remain
> (ada0:ahcich0:0:0:0): SEND_FPDMA_QUEUED DATA SET MANAGEMENT. ACB: 64 01 00
> 00 00 40 00 00 00 00 00 00
> (ada0:ahcich0:0:0:0): CAM status: Uncorrectable parity/CRC error
>
>
> any ideas what is a problem?
>

The drive is reporting that it supports SDM. However, it's returning a
weird error code
when fed the DSM we're sending it.

First, it could be a bug in how it does queued DSM requests. Normally one
can queue
up a bunch of trim requests on newer drives. Perhaps this one gets cranky.

Next, maybe the drive is lying the size of the DSM it will support, but
again, this is a weird
message to report a request that's too long with.

Maybe it doesn't support queued DSM, despite all appearances to the
contrary from its
identify tables. Try setting the trem method to DSM_TRIM:
# sysctl kern.cam.ada.0.delete_method=DSM_TRIM
should do the trick. At the very least, that will change the command we
send so if it can't
handle that, then the error message will change. I suspect this may clear
up the problem.

There's a few other things it can be, but if it is only trim commands that
suffer from this, then
they are quite unlikely.

Warner