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-scdbac...@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-scdbac...@gmx.net/raw Have a nice day :) Thomas
