[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-xorriso] Burning on two drives at the same time slows down rate
From: |
Thomas Schmitt |
Subject: |
Re: [Bug-xorriso] Burning on two drives at the same time slows down rate and xorriso crashes |
Date: |
Thu, 12 Oct 2017 23:19:40 +0200 |
Hi,
sean loony wrote:
> Writing rate on drive one goes down to 0.1D and stays there till the
> end. While writing on drive one, drive two has the same slow speed.
This is a known problem with Linux since september 2010.
Introduced by this drive-by programming effort:
https://lkml.org/lkml/2010/9/14/338
A fix in the kernel would be to remove
mutex_lock(&sr_mutex);
and
mutex_unlock(&sr_mutex);
from function sr_block_ioctl() in drivers/scsi/sr.c . See
https://github.com/torvalds/linux/blob/master/drivers/scsi/sr.c
There are two workarounds known:
- Use /dev/sg* instead of /dev/sr* by command
-scsi_dev_family sg
which is available since xorriso-1.4.4.
- Use an old workaround for separating i/o on IDE master-slave pairs
by command
-modesty_on_drive on:min_percent=90:max_percent=95
which is available since xorriso-1.4.2.
For the long story see:
https://dev.lovelyhq.com/libburnia/web/wikis/Concurrentlinuxsr
> While formating, the rate of USB drive goes down to 0.1xD an after a
> while to 0.0 and then xorriso freezed.
In the mail subject you wrote "crashes".
What exactly: Freeze or crash ? Stuck or ended ?
Well, the situation in the kernel is a mess. In the stack trace you
can see the well known culprits:
[193932.477570] mutex_lock+0x28/0x30
[193932.477575] sr_block_ioctl+0x2e/0xb0
It looks like not even the mutex works properly, additionally to the
fact that the mutex usage is a mindless substitute for the Big Kernel
Lock with its property to be suspended when a process goes to sleep.
Have a nice day :)
Thomas