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
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:
Obviously the deprecated device file family /dev/sg* does not have such
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
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*:
Meanwhile the releases on [wiki:Releases release page]
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
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
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.
Some drive firmwares work well with partly empty buffer, some don't.
Regrettably there is no similar remedy known for reading from /dev/sr*
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.
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.
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.