From 0bc24760333ed43e41f6805802817dd6a6c75921 Mon Sep 17 00:00:00 2001 From: Thomas Schmitt Date: Tue, 7 Jul 2020 13:27:20 +0000 Subject: [PATCH] --- ConcurrentLinuxSr.md | 161 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 161 insertions(+) create mode 100644 ConcurrentLinuxSr.md diff --git a/ConcurrentLinuxSr.md b/ConcurrentLinuxSr.md new file mode 100644 index 0000000..d0ff447 --- /dev/null +++ b/ConcurrentLinuxSr.md @@ -0,0 +1,161 @@ +# The problems with concurrent burns on Linux + +Beginning with high version numbers of Linux kernel 2.6 and up to +at least kernel 4.3.0 there is a performance problem when more than +one optical drive is used for burning or reading via libburn at the same time. +The overall throughput is less than the throughput of the slowest drive +when it is used as only one. + +This affects SATA and USB attached drives alike. Most probably also IDE +attached ones. + + +## Kernel theory + +The most plausible explanation for the problem is the introduction +of a global lock for all optical drives which is held during the +whole transaction time of `ioctl(SG_IO)`. +This ioctl is used by libburn to send SCSI commands to the burner +drive. So each single burner blocks the other libburn processes +until it has ended its transaction. + +See the problematic changeset which affected `drivers/scsi/sr.c` among +many other kernel parts: + + https://lkml.org/lkml/2010/9/14/338 + +and the summary of consequences with remedy proposal: + + http://marc.info/?l=linux-scsi&m=135705061804384&w=2 + +Obviously the deprecated device file family `/dev/sg*` does not have such +a lock. + +# Consequences for libburn + +## Using /dev/sg* against all good advise + +The libburn call `burn_preset_device_open()`, cdrskin option +`drive_scsi_dev_family=`, and xorriso command `-scsi_dev_family` +can cause libburn to use `/dev/sg*` instead of `/dev/sr*`. +Without such special setting a `/dev/sg*` address given by the user would +be mapped to the corresponding `/dev/sr*`. + +These runs of version 1.4.4 or higher can coexist without throughput +problems: +``` +xorriso -scsi_dev_family sg -dev /dev/sr0 -map ./data /data +``` +``` +xorriso -as cdrecord drive_scsi_dev_family=sg dev=/dev/sr1 -v image2.iso +``` +``` +cdrskin drive_scsi_dev_family=sg dev=/dev/sr3 -v image3.iso +``` + +### /dev/sg with older versions of cdrskin + +A bug in libburn-0.5.2 to 1.4.2 prevented automatic conversion from `/dev/sr*` +addresses to `/dev/sg*` addresses if `drive_scsi_dev_family=sg` is given. +xorriso up to version 1.4.2 did not offer the opportunity to use `/dev/sg*`. + +Nevertheless it is possible to let older cdrskin versions work with `/dev/sg*`: +``` +$ cdrskin drive_scsi_dev_family=sg --devices +... + 0 dev='/dev/sg2' rwrw-- : 'HL-DT-ST' 'BDDVDRW GGC-H20L' + 1 dev='/dev/sg3' rwrw-- : 'HL-DT-ST' 'DVDRAM GH24NSC0' + 2 dev='/dev/sg4' rwrw-- : 'ASUS ' 'BW-16D1HT' + 3 dev='/dev/sg5' rwrw-- : 'HL-DT-ST' 'BD-RE GGW-H20L' + 4 dev='/dev/sg6' rwrw-- : 'Optiarc ' 'BD RW BD-5300S' +``` +``` +$ cdrskin drive_scsi_dev_family=sg dev=/dev/sg2 -v image1.iso +$ cdrskin drive_scsi_dev_family=sg dev=/dev/sg3 -v image2.iso +$ cdrskin drive_scsi_dev_family=sg dev=/dev/sg6 -v image3.iso +``` + +Meanwhile the releases on [release page](Releases) +have the bug fixed and xorriso augmented by a new command. + +## Staying with /dev/sr* as bad as it is + +Despite the fine performance of `/dev/sg*` it remains desirable to use +`/dev/sr*` because `/dev/sg` is deprecated by the kernel developers, +the translation from `/dev/sr` to `/dev/sg` is not guaranteed to work in future, +and `/dev/sr*` is better coordinated with `mount(8)` and `open(2)` for +`read(2)`. + +So long lasting SCSI transactions via `/dev/sr*` cause long +delays of communication with the other drives. Some of these delays +cannot be avoided. +E.g. the SCSI command to eject the tray needs several seconds to be +completed. + +Another long delay can be circumvented, though: + +If the buffer of a drive is nearly full and a WRITE command +arrives, then the drive may delay the reply until there is room +in the buffer for the next WRITE command. +Depending on the firmware and buffer size, this may last quite some +time. Further the time granularity of lock waiting seems quite coarse. + +These long waiting WRITE commands can be avoided if libburn keeps +itself from filling the drive buffer to a level where the firmware +would begin to delay the reply. + +xorriso command `-modesty_on_drive`, cdrskin option +`modesty_on_drive=`, and libburn call `burn_drive_set_buffer_waiting()` +apply a strategy which stems from the days of IDE when the slow CD drive +clogged the IDE controller which it shared with a HDD. + +Example: +``` + -modesty_on_drive on:min_percent=90:max_percent=95 +``` + +Some drive firmwares work well with partly empty buffer, some don't. + +Regrettably there is no similar remedy known for reading from /dev/sr* +via ioctl(SG_IO). + +### Parameter considerations + +Those drives which can work well with `-modesty_on_drive` still may need +adjustment of the modesty parameters. + +The threshold for delaying further WRITE commands is controlled by +parameter `max_percent`. The threshold for resuming to send WRITE +commands is `min_percent`. + +So if `min_percent=90:max_percent=95` does not show the desired effect +of reaching about 80 to 90 percent of the throughput of an undisturbed +burn run of a single burner, then one has to try variations. +Keep in mind that `min_percent` has to stay lower than `max_percent`. + +Drives have been observed to report their buffer fill too low. This +risks to send a long blocking WRITE command by mistake. +A lower `max_percent` percent value may compensate. +``` + -modesty_on_drive on:min_percent=75:max_percent=80 +``` + +Drives have been observed to become even slower by waiting for more +input before writing if their buffer is not full enough. +A higher `min_percent` may help. +``` + -modesty_on_drive on:min_percent=95:max_percent=97 +``` + +Drives have been observed to slow down their write speed if the +input comes in small amounts with some short waiting time inbetween. +A larger gap between `min_percent` and `max_percent` may help +to get larger write amounts without intermediate waiting. +``` + -modesty_on_drive on:min_percent=75:max_percent=95 +``` + +Finally there are drives which perform poorly with stream recording if +their buffer is not completely full. This means that they will not +be able to burn DVD-RAM, BD-RE, or formatted BD-R at full nominal speed +if `-modesty_on_drive` is set to `on`.