Re: Kernel global lock in sr.c slows down parallel operations to multiple drive
Hi,
> In jessie, the kernel had a very annoying bug: if you did I/O on
> multiple sr devices, the global lock in sr.c would slow down
> to a crawl.
I dedicated a little temple to that bug.
https://dev.lovelyhq.com/libburnia/web/wiki/ConcurrentLinuxSr
In short:
- It is gone since about kernel 5.6 or 5.7. The mutex is now per drive.
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=51a858817dcd
- On older kernels use /dev/sg and be free of the global sr mutex.
- Or change the kernel to perform the mutex in sr_block_ioctl() only if
cmd != SG_IO. I tested that with kernel 4.19 of Debian 10.
But above committed fix is better, as it also eases fixing of the
automatic tray loading bug.
> I will try to apply a similar patch and possibly report another bug.
What is that other bug ?
I know of and have patches for:
- Automatic tray loading quickly reporting no medium.
- I/O error at the end of data CDs written by Track-At-Once.
- Non-zero size of empty drive or empty medim.
- Wrong buffers, medium state and size after burning until tray reloading.
- No mount(8) option session= with DVD.
- Some fs/isofs bugs, too.
---------------------------------------------------------------------
I try to submit a fix for the tray bug since more than two months.
So if you want to help improving sr and have a drive with motorized tray,
then consider to test whether you suffer from it and whether my proposed
patches fix it for data reading:
https://lore.kernel.org/linux-scsi/20201006094026.1730-1-scdbackup@gmx.net/T/#u
If it works for you, please send a reply mail with a "Tested-by:".
Full mail headers can be seen at
https://lore.kernel.org/linux-scsi/20201006094026.1730-1-scdbackup@gmx.net/raw
Have a nice day :)
Thomas
Reply to: