[Pkg-opt-media-team] Bug#709971: dvd+rw-tools: growisofs more then 1 Bluray, since Debian 7 speed collapses
Winfried Münch
winfried.muench at abk.de
Wed Jun 5 17:55:08 UTC 2013
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 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 blocks read in 43 s , 1.1xB
> ...
> 28 00 00 03 b5 e0 00 00 10 00
> 848 ms
> xorriso : UPDATE : 243184 of 320001 blocks read in 53 s , 0.9xB
>
> They often coincide with the pacifier messages of xorriso which
> come every five five seconds (or longer, if reading via ioctl(SG_IO)
> stalls).
>
> This coincidence gives me the suspicion that the long lasting
> READ commands need much more time than the about 0.8 seconds
> which are reported by the kernel's time measurement with
> ioctl(SG_IO):
> struct sg_io_hdr_t.duration
>
> (I will have to improve the SCSI log by own time measurements
> in userspace which hopefully give a granularity finer than
> than 4 milliseconds.)
>
>
> The write log shows shorter stalls.
> They appear to be grouped as pairs with 6 to 8 intermediate
> fast command executions inbetween. Between pairs there are
> longer periods of fast execution:
>
> WRITE(10)
> 2a 00 00 03 64 60 00 00 10 00
> 108 ms
> ... 7 fast ones ...
> 2a 00 00 03 64 d0 00 00 10 00
> 44 ms
> ---------------------------------
> 2a 00 00 03 71 40 00 00 10 00
> 124 ms
> ... 7 fast ones ...
> 2a 00 00 03 71 b0 00 00 10 00
> 40 ms
> ---------------------------------
> 2a 00 00 03 7e 80 00 00 10 00
> 112 ms
> ... 8 fast ones ...
> 2a 00 00 03 7f 10 00 00 10 00
> 36 ms
> ---------------------------------
> 2a 00 00 03 8b 20 00 00 10 00
> 108 ms
> ... 6 fast ones ...
> 2a 00 00 03 8b 90 00 00 10 00
> 48 ms
>
> The bytes 3 to 6 of each WRITE command tell the block address
> (printed as hex here, little-endian, block size 2048).
>
> Each READ and WRITE command transferred 32 KiB.
>
>
> -----------------------------------------------------------------
> Some non-kernel proposals for a workaround:
>
> One could try to increase the transfer size to 64 KiB.
> This reduces the number of commands by a factor of 2 and
> might also please driver or burner drive if they put emphasis
> on the natural ECC block size of BD media.
>
> Writing:
>
> xorriso -scsi_log on \
> -as cdrecord -v dev=/dev/srX \
> dvd_obs=64k \
> filename.iso \
> > /tmp/xorriso_write_log 2>&1
>
>
> Reading:
>
> time xorriso -scsi_log on \
> -outdev /dev/srX \
> -check_media use=outdev min_lba=0 max_lba=320000 \
> chunk_size=64s -- \
> > /tmp/xorriso_read_log 2>&1
>
>
> If you can trust the quality of drives and media, then you may
> disable Defect Management during writing:
>
> xorriso -scsi_log on \
> -as cdrecord -v dev=/dev/srX \
> stream_recording=on \
> filename.iso \
> > /tmp/xorriso_write_log 2>&1
>
> This should bring the effective write speed much nearer to the
> nominal speed of drive and medium. libburn will use WRITE(12)
> rather than WRITE(10).
> (stream_recording=on on BD media implies dvd_obs=64k but you
> may well give that option explicitely, too.)
>
> If you record checksums of the image files, then you could
> use them to verify success with (simultaneously fast) dd
> reading.
> Even without checksum, a properly readable data stream of
> the image's size will give you good certainty that the burn
> went well. (If you get I/O error from dd, then it is bad. :))
>
> The practical benefit of Defect Management is limited anyway.
> It usually fails earlier than write runs without this feature.
> A few bad spots can be worked around, but the usual problematic
> medium will just fail more spectacular then.
>
> -----------------------------------------------------------------
>
> Have a nice day :)
>
> Thomas
>
> --
> To unsubscribe, send mail to 709971-unsubscribe at bugs.debian.org.
>
>
----------------------------------------------------------------------
ABK-Systeme GmbH, Am Weiher 1-3, D-63303 Dreieich
Telefon: +49-(0)6103-98720 - Fax: +49-(0)6103-9872-22
E-Mail: info at abk.de - Internet: http://www.abk.de
Reg.-Nr.: HRB 31631, Amtsgericht Offenbach - Ust.-ID-Nr.: DE 11352 783
Geschaeftsfuehrer: Armin Gerhardt
EFiS-EDI Finance Service AG, Am Weiher 3, D-63303 Dreieich
Telefon: +49-(0)6103-98720 - Fax: +49-(0)6103-9872-22
E-Mail: info at efis.de - Internet: http://www.efis.de
Reg.-Nr.: HRB 40398 - Amtsgericht Offenbach - Ust.-ID-Nr.: DE 11352 7971
Aufsichtsratsvorsitzender: Dr. Michael Roechner
Vorstandsvorsitzender: Armin Gerhardt
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Diese Nachricht kann vertrauliche Informationen enthalten. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir Sie, den Absender unverzueglich zu informieren und die E-Mail zu loeschen. Jeder unbefugte Zugriff oder jede unbefugte Weiterleitung, die Fertigung einer Kopie, die Veroeffentlichung oder sonstige in diesem Zusammenhang stehende Handlung ist untersagt. Da wir nicht die Echtheit oder Vollstaendigkeit der in dieser Nachricht enthaltenen Informationen garantieren koennen, schließen wir die rechtliche Verbindlichkeit der vorstehenden Erklaerungen und Aeusserungen aus.
This message may contain confidential information. If you are not the intended recipient please promptly inform the sender and delete this email. Any other unauthorized access or unauthorized forwarding, copy creation, publication or any other action in this connection is prohibited. As we cannot guarantee the genuineness or completeness of the information contained in this message, the statements set forth above are not legally binding.
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
More information about the Pkg-opt-media-team
mailing list