Hi,
meanwhile the moment of breaking the kernel has been identified.
It was the mass removal of Big Kernel Lock in 2010 by Arnd Bergmann:
https://lkml.org/lkml/2010/9/14/338
A summary of problem reports and investigations was posted to LKML in 2013
Hi,
meanwhile i am on Debian 8.1, kernel 3.16 and suffer from
the described problems myself.
The behavior resembles old IDE master-slave concurrency
problems. (Disk at /dev/hdc, burner at /dev/hdd.)
There is a coarse workaround from those old times.
cdrecord introduced options -immed and
Hi,
there is a discussion going on, which might be related
to this bug report:
http://www.spinics.net/lists/linux-scsi/msg69679.html
This discussion states that SG_IO is serialized by a mutex,
and that this probably can be eased.
It does not explain why Winfried experiences a reduction
of
Hi,
(Somehow my subscription to bug 709971 did not forward
your recent mail to me. I found it by Google.)
my 5. Child was born on 20.6.
Congrats !
Please give me advice for the next tests. Should I repeat the xorriso
write and read tests on the same time?
The improved time measurement
Hi,
i have uploaded
http://www.gnu.org/software/xorriso/xorriso-1.3.1.tar.gz
with improved time measurement in the SCSI log.
The time measurement is now done in userspace by gettimofday()
or optional clock_gettime(CLOCK_MONOTONIC).
The shown granularity is microseconds.
Additionally there is
Hi,
I tested the actual stabel kernel 3.9.4 and see the same problem.
So it is clear that we have some regression in the kernel.
growisofs and/or libburn would be at most to blame for not
knowing the newest tricks to get the same performance as on
the old kernels.
Do you have an idea how to
Hi,
i am pondering about the high cost of experiments with this
issue. Regrettably, BD-R offer no dummy burning by growisofs
-use-the-force-luke=dummy resp. by xorriso -as cdrecord -dummy.
But high speed DVD-R burning should transmit 20 MB/s near the
end of the medium when speed surpasses 14x.
Hi,
I tested the actual stabel kernel 3.9.4 and see the same problem. only a
eject on a other drive brings the write speed down to 0.4x to 0.8x.
So next I will test with the 64k bs...
Winfried
Am Mi, 5.06.2013, 20:47, schrieb Thomas Schmitt:
Hi,
a non-kernel workaround should not be the
Hi,
i noticed this message of the xorriso -check_media run:
libburn : WARNING : Last session on media is still open.
This might be a consequence of the growisofs bug.
What do you get if you inspect this medium by
dvd+rw-mediainfo /dev/srX
or
xorriso -outdev /dev/srX -toc
Have a nice
Hi,
meanwhile i got the SCSI logs from Winfried Muench.
The read log shows long hangs
READ(10)
28 00 00 02 74 80 00 00 10 00
844 ms
xorriso : UPDATE : 160912 of 320001 blocks read in 36 s , 0.6xB
...
28 00 00 03 07 e0 00 00 10 00
856 ms
xorriso : UPDATE : 198640 of 320001
Hi,
i wrote:
the kernel's time measurement with ioctl(SG_IO):
struct sg_io_hdr_t.duration
Just to avoid raised eyebrows if kernel programmers see this:
The word struct here was an error of mine.
The time measurement component is defined in scsi/sg.h as
part of the ioctl(SG_IO) parameter
Hi, I had burnd one BD with growisofs sr0info und one with xorriso sr1info:
root@bluray:/space/isotmp/test# cat sr0info sr1info
INQUIRY:[HL-DT-ST][BD-RE BH10LS30 ][1.01]
GET [CURRENT] CONFIGURATION:
Mounted Media: 41h, BD-R SRM
Current Write Speed: 8.0x4495=35964KB/s
Hi,
a non-kernel workaround should not be the goal, because the Bug is comming
from change debian 6 to 7. So there must be changes between kernel
2.6.32.5 and 3.2.0.4 for ioctl. I will test a newer kernel asap.
Bye
Winfried
Am Mi, 5.06.2013, 16:00, schrieb Thomas Schmitt:
Hi,
meanwhile i
Hi,
a non-kernel workaround should not be the goal,
Not a final goal, indeed.
But maybe we learn more from writing chunks of 64 KiB.
So there must be changes between kernel
2.6.32.5 and 3.2.0.4 for ioctl
I assume it's in the levels below the ioctl(). There is queing
of command requests,
Hi again,
While write a BD on /dev/sr0 a second Terminal i try eject /dev/sr2 and I
see:
root@bluray:/space/isotmp/test# eject /dev/sr2
eject: Kann nicht auswerfen! Letzter Fehler: Unpassender IOCTL
(I/O-Control) für das Gerät
and the write speed slow down:
8250392576/12100028416 (68.2%) @3.0x,
Hi,
to your questions:
all the drives attached via internal SATA Connections. Hardware is not
changed between Debian 6 and 7. The System with Debian 6 is also for Tests
availible.
Read Test with dd:
only one drive on Work:
root@bluray:/space/isotmp/test# date time dd if=$LW of=`basename
Hi,
eject: Kann nicht auswerfen! Letzter Fehler: Unpassender IOCTL
(I/O-Control) für das Gerät
Jetzt duerfen wir raten, was das fuer ein Fehler war ...
(= Now we may guess what error this was ...)
Google brings me to
#define ENOTTY 25 /* Not a typewriter */
Whatever, a
Hi,
this would be a blow for burn programs. I am maintaining libburn
and its applications cdrskin and xorriso. So i am interested in this
problem.
The main suspect would be the kernel in this case. The programs send
SCSI commands via ioctl(SG_IO) and wait until this ioctl call ends.
If they are
Package: dvd+rw-tools
Version: 7.1-10
Severity: normal
Dear Maintainer,
in our Company we are burning offten BackupData on Bluray. So we use a PC with
4 Bluray Drives. In the Past we work on Debian 6.0.7 i386 without X11.
Login per ssh and start 4x growisofs -Z /dev/srX filename.iso so all
19 matches
Mail list logo
