[Paranoia] Parallel ripping causes extreme slowdowns

[grarpamp]

>> This was indeed the problem. The problem was not related to the
>> USB<->SATA bridges, but indeed in the sr driver itself, see inline.

>>>> seems like there is never an instance where commands to both the drives
>>>> (or more than two, really) are submitted at the same time. That is, it
>>>> seems like Linux always waits for one command to complete before
>>>> submitting another one, even though the device is on a different SCSI

Sometimes checking Linux vs FreeBSD can help users narrow down
that sort of hardware, kernel, userland. But only if people know
both OS to boot and compare, let alone go kernel diving.

>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/drivers/scsi/sr.c?id=2a48fc0ab24241755dc93bfd4f01d68efab47f5a
>>> I guess next steps are to see how this can be turned into a per device
>>> mutex.
>> With a simple change to drivers/scsi/sr.c and drivers/scsi/sr.h
>> (introducing a per-device lock to struct scsi_cd, replacing sr_mutex
>> with a per device lock) - the problem no longer occurs and reads from
>> different sr devices happily interleave:
>> Will see if I can turn this into a patch that can be accepted on

Sure. If not the patch could be added to cdparanoia contrib.
But I have no idea if anyone is collecting and
committing and where, any updates from this list
and the various OS ports since last cdparanoia release.
Hopefully work isn't getting lost.

> Perhaps I'm a bit biased, but have you thought of using a sg device
> rather than a sr device? lsscsi will show you the mapping between the
> two.

If I recall, cdda2wav from cdrtools has some interface with 'sg'.


> The original USB Mass Storage protocol is !@#$. Avoid it at all costs.
> It collapses all SCSI error code (often spread across 18 bytes) into
> a single bit: it worked or it didn't.

> UAS(P) is the way to go, if you can get it. I have a USB-C to SATA dongle
> here that does UAS: