parent
da632d90c5
commit
0bc2476033
161
ConcurrentLinuxSr.md
Normal file
161
ConcurrentLinuxSr.md
Normal file
@ -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`.
|
||||||
Loading…
Reference in New Issue
Block a user