Just an update on this. I deconfigured and removed one of the existing
disks, and installed the Samsung 870 EVO in its place. I then tried the
database load again. This time, it ran to completion with - apparently
- no problems.

So the fact that I was using the disk via USB3 does seem to have been a
factor in the problems I was experiencing. It would be nice to
understand this! I've seen mentions that UAS (USB attached SCSI) has
been known to cause strange problems with some SSDs - but I've not been
able to dig very deeply into this (so far). Apparently it's possible to
disable UAS (in which case, the system goes back to using the old USB
bulk-only transport protocol. At some point, I'm intending to try this
with the SSD which was having the problems.

Anthony - thanks for prompting me into looking into this. It's
definitely been useful.

On Fri, 2022-11-18 at 16:59 +0100, Antony Stone wrote:
> On Friday 18 November 2022 at 16:55:59, Peter Duffy wrote:
>
> > I should also have mentioned that I've run the self-test on the
> > drive
> > (no problems reported) and verified that the drive firmware is at
> > the
> > level currently being offered by Samsung for download.
>
> I would suspect the interface you're using to connect it over USB3.
>
> Do you have any opportunity to connect it to a spare SATA connector
> on the
> motherboard, as a comparison?
>
>
> Antony.
>
> > On Fri, 2022-11-18 at 15:30 +0000, Peter Duffy wrote:
> > > Correction - they're Samsung 870 EVOs.
> > >
> > > Sorry.
> > >
> > > On Fri, 2022-11-18 at 15:25 +0000, Peter Duffy wrote:
> > > > I recently bought a couple of Samsung 1T EVO 970 SSDs to do
> > > > some
> > > > work:
> > > > basically I need to simulate the loading of a fairly big mysql
> > > > database
> > > > (>80G). I'm currently hitting a very weird problem.
> > > >
> > > > The mysql is percona 5.7. I attach the disk via USB3, partition
> > > > it,
> > > > create an ext4 fs on one of the partitions, mount it, create a
> > > > directory on it, configure mysql to use it as the datadir, and
> > > > then
> > > > initialise it for mysql use. All good so far. I then start the
> > > > mysql
> > > > dataload, and it's progressing happily.
> > > >
> > > > Then the mysql server bombs out, and messages like the
> > > > following
> > > > appear
> > > > in the dmesg output:
> > > >
> > > > [19718.093317] sd 12:0:0:0: [sdf] tag#21 FAILED Result:
> > > > hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=27s
> > > > [19718.093327] sd 12:0:0:0: [sdf] tag#21 Sense Key : Illegal
> > > > Request
> > > > [current]
> > > > [19718.093330] sd 12:0:0:0: [sdf] tag#21 Add. Sense: Invalid
> > > > command
> > > > operation code
> > > > [19718.093333] sd 12:0:0:0: [sdf] tag#21 CDB: Synchronize
> > > > Cache(10)
> > > > 35 00 00 00 00 00 00 00 00 00
> > > > [19718.093340] blk_update_request: critical target error, dev
> > > > sdf,
> > > > sector 0 op 0x1:(WRITE) flags 0x800 phys_seg 0 prio class 0
> > > >
> > > > I'm trying to decide whether I'm just dealing with a borked SSD
> > > > (it
> > > > came from Amazon: yeah, I know - if I will buy SSDs from that
> > > > source,
> > > > what do I expect?) - or something more subtle and/or complex.
> > > > Reading
> > > > the above messages literally, they seem to indicate that a
> > > > command
> > > > is
> > > > being sent to the SSD and it's not understanding it.
> > > >
> > > > Any thoughts would be most gratefully welcomed.
>