On Mon, Aug 29, 2022 at 1:20 AM Damien Le Moal
<damien.lemoal@xxxxxxxxxxxxxxxxxx> wrote:
> On 2022/08/26 21:00, Peter Fröhlich wrote:
> > In commit 8ae720449fca4b1d0294c0a0204c0c45556a3e61 "libata: whitespace
> > fixes in ata_to_sense_error()" we find, among many actual whitespace
> > changes, another change that adds an entry for 0x40 to the stat_table.
> > ...
>
> See the code below that table definition. You can see this hunk:
>
> if (drv_err) {
> /* Look for drv_err */
> for (i = 0; sense_table[i][0] != 0xFF; i++) {
> /* Look for best matches first */
> if ((sense_table[i][0] & drv_err) ==
> sense_table[i][0]) {
> *sk = sense_table[i][1];
> *asc = sense_table[i][2];
> *ascq = sense_table[i][3];
> goto translate_done;
> }
> }
> }
That's the sense_table, I was referring to the stat_table. That table
is consulted when we fail to convert via the sense_table.
> Are you using an SMR drive ? Getting an aligned write should not happen for a
> regular disk as the kernel ensure alignments of IO to LBAs. But for SMR, it is
> possible to send a write command that is not aligned to a zone write pointer
> position, resulting in an unaligned write error.
Which is why I am pretty sure that the "unaligned write" message is
spurious since I am writing to a plain old SSD. It's going to be hard
for a userspace program to generate a write that is no properly
aligned for the SSD.
Cheers,
Peter
