bug-xorriso
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]