Bug#709971: dvd+rw-tools: growisofs more then 1 Bluray, since Debian 7 speed collapses
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 https://marc.info/?l=linux-scsi=135705061804384=2 where one mutex per drive is proposed. But actually ioctl(SG_IO) is rarely used by multiple users per drive. So a lock per drive can hardly solve problems which might arise when the common mutex for all drives gets removed. So all or nothing: I would just remove from function drivers/scsi/sr.c:sr_block_ioctl() the lines mutex_lock(_mutex); and mutex_unlock(_mutex); With xorriso i use since two years /dev/sg rather than /dev/sr on a vanilla kernel 3.16. https://dev.lovelyhq.com/libburnia/web/wikis/ConcurrentLinuxSr sg did not have the Big Kernel Lock when the mass removal happened. So it got no mutex and still works with normal performance on multiple drives. Except the consequential poor coordination with "mount" and "eject" there are no negative effects to see. Regrettably the attempt to use /dev/sg with growisofs fails: $ growisofs -Z /dev/sg5=debian-8.8.0-amd64-netinst.iso Executing 'builtin_dd if=/dvdbuffer/debian-8.8.0-amd64-netinst.iso of=/dev/sg5 obs=32k seek=0' :-( write failed: Illegal seek $ growisofs uses POSIX i/o to read from the medium. This would have to be changed to SCSI READ commands via ioctl(SG_IO) before /dev/sg would be usable as drive address. Have a nice day :) Thomas
Bug#709971: dvd+rw-tools: growisofs more then 1 Bluray, since Debian 7 speed collapses
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 minbuf=, which keep the drive buffer hungry and so avoid that the kernel has to wait with a pending WRITE command until the buffer has enough room. growisofs does not have it, xorriso development just got it, but cdrskin has it since quite a while. This allows me to burn with 4x DVD+RW speed, 2.3x BD-RE speed, and 2.0x BD-RE speed simultaneously (about 24 MB/s in total): cdrskin -v dev=/dev/sr1 minbuf=65 filename.iso cdrskin -v dev=/dev/sr2 minbuf=65 filename.iso cdrskin -v dev=/dev/sr4 minbuf=65 filename.iso Burners are LG GH24NSC0 (SATA), LG GGW-H20L (USB-SATA), LG BH16NS40 (USB-SATA). Mainboard ASUS P9D WS. 3.4 GHz Xeon. It does not work well with BD-RE on Optiarc BD-5300S when Defect Management is disabled. In this case the burner seems to wait for a full buffer, while libburn waits for half-empty buffer. After a few seconds the burner empties the buffer and the next write-and-wait cycle begins. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709971: dvd+rw-tools: growisofs more then 1 Bluray, since Debian 7 speed collapses
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 performance when switching from Debian 6 to 7. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709971: dvd+rw-tools: growisofs more then 1 Bluray, since Debian 7 speed collapses
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 might a give clearer view on the symptoms. Granularity is much finer and the timestamps will tell whether libburn stalls at other occasions than waiting for an SCSI transaction call ioctl(SG_IO) to end. So repeat the tests which showed the problem. Show me the resulting log files. After those logs are generated and inspected, the problem probably will leave my realm of driving optical drives. It looks like a kernel i/o queue congestion. You will have to look for kernel experts who are interested in debugging this behavior. I will be ready to explain to them what libburn or growisofs are doing. (Cc me when you have found interested developers.) Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709971: dvd+rw-tools: growisofs more then 1 Bluray, since Debian 7 speed collapses
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 a timestamp in []-brackets which tells the elapsed microseconds since startup of libburn. The timestamps can be used to determine the time between two SCSI commands resp. ioctl(SG_IO) calls. E.g there is a time gap of 133672-130285-1936 = 1451 microseconds between the end of the first command and the start the next one: PREVENT/ALLOW MEDIA REMOVAL 1e 00 00 00 00 00 6394 us [ 130285 ] START/STOP UNIT 1b 00 00 00 03 00 1936 us [ 133672 ] Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709971: dvd+rw-tools: growisofs more then 1 Bluray, since Debian 7 speed collapses
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 switch this Debian bug report from dvd+rw-tools to kernel ? Will you report to LKML ? I am ready to support such reports by explanations about growisofs and/or libburn. Please give me a note where to see it when submitted. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709971: dvd+rw-tools: growisofs more then 1 Bluray, since Debian 7 speed collapses
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. These media can be used with above dummy options. They will stay unused (but may behave like being written until they get ejected). Another non-wasteful media type could be 4x BD-RE in conjunction with xorriso -as cdrecord stream_recording=on . (See man xorrecord for xorriso -as cdrecord options. -use-the-force-luke of growisofs is intentionally undocumented and ihas to be learned from the source code.) Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709971: dvd+rw-tools: growisofs more then 1 Bluray, since Debian 7 speed collapses
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 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, driver code for particular busses and controller boards, ... lots of room to look for bugs. I will test a newer kernel asap. This will at least clarify whether it was a short living problem in the kernel. --- growisofs sr0info [...] xorriso sr1info: Strange. The first mediainfo reports Mounted Media: 41h, BD-R SRM which would match the media state that is used by libburn underneath xorriso. The second one is Mounted Media: 41h, BD-R SRM+POW which would match growisofs. But this from the first one does not look like the libburn results on my own BD burners: Disc status: complete Number of Sessions:1 State of Last Session: complete Number of Tracks: 1 READ TRACK INFORMATION[#1]: Track State: complete incremental Track Start Address: 0*2KB Free Blocks: 0*2KB Track Size:12219392*2KB Last Recorded Address: 5908367*2KB This is a closed medium (use xorriso -as cdrecord option -multi to keep it appendable if this is desired). But why does the drive report as track size the whole medium ? Well, the read size info looks ok: READ CAPACITY: 5908368*2048=12100337664 Probably the message by xorriso is a consequence of the Pseudo Overwrite formatting which growisofs applied. Hard to say whether this is sane or not. libburn does not do POW. The growisofs medium is appendable. But that does not mean it would have an incomplete session. (I will have to invest a BD-R for learning more about the doings of growisofs on these media.) Have a nice day :) Thomas -- To unsubscribe, send mail to 709971-unsubscr...@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: i...@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: i...@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. +++ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709971: dvd+rw-tools: growisofs more then 1 Bluray, since Debian 7 speed collapses
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 day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709971: dvd+rw-tools: growisofs more then 1 Bluray, since Debian 7 speed collapses
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 21 Reading: time xorriso -scsi_log on \ -outdev /dev/srX \ -check_media use=outdev min_lba=0 max_lba=32 \ chunk_size=64s -- \ /tmp/xorriso_read_log 21 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 21 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, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709971: dvd+rw-tools: growisofs more then 1 Bluray, since Debian 7 speed collapses
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 struct which gets defined
as type sg_io_hdr_t:
typedef struct sg_io_hdr
{
...
unsigned int duration; /* [o] time taken by cmd (unit: millisec) */
...
} sg_io_hdr_t;
Have a nice day :)
Thomas
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709971: dvd+rw-tools: growisofs more then 1 Bluray, since Debian 7 speed collapses
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 Write Speed #0:8.0x4495=35964KB/s Write Speed #1:6.0x4495=26973KB/s Write Speed #2:4.0x4495=17982KB/s Write Speed #3:2.0x4495=8991KB/s Speed Descriptor#0:02/5908367 R@7.6x4495=33950KB/s W@8.0x4495=35964KB/s Speed Descriptor#1:02/5908367 R@7.6x4495=33950KB/s W@6.0x4495=26973KB/s Speed Descriptor#2:02/5908367 R@7.6x4495=33950KB/s W@4.0x4495=17982KB/s Speed Descriptor#3:02/5908367 R@7.6x4495=33950KB/s W@2.0x4495=8991KB/s READ DISC INFORMATION: Disc status: complete Number of Sessions:1 State of Last Session: complete Number of Tracks: 1 READ TRACK INFORMATION[#1]: Track State: complete incremental Track Start Address: 0*2KB Free Blocks: 0*2KB Track Size:12219392*2KB Last Recorded Address: 5908367*2KB FABRICATED TOC: Track#1 : 14@0 Track#AA : 14@5908368 Multi-session Info:#1@0 READ CAPACITY: 5908368*2048=12100337664 INQUIRY:[HL-DT-ST][BD-RE BH10LS30 ][1.01] GET [CURRENT] CONFIGURATION: Mounted Media: 41h, BD-R SRM+POW Current Write Speed: 8.0x4495=35964KB/s Write Speed #0:8.0x4495=35964KB/s Write Speed #1:6.0x4495=26973KB/s Write Speed #2:4.0x4495=17982KB/s Write Speed #3:2.0x4495=8991KB/s GET [CURRENT] PERFORMANCE: Write Performance: 4.2x4495=19076KB/s@0 - 8.0x4495=35964KB/s@5767167 8.0x4495=35964KB/s@[5767168 - 11826175] Speed Descriptor#0:02/11826175 R@9.9x4495=44479KB/s W@8.0x4495=35964KB/s Speed Descriptor#1:02/11826175 R@9.9x4495=44479KB/s W@6.0x4495=26973KB/s Speed Descriptor#2:02/11826175 R@9.9x4495=44479KB/s W@4.0x4495=17982KB/s Speed Descriptor#3:02/11826175 R@9.9x4495=44479KB/s W@2.0x4495=8991KB/s POW RESOURCES INFORMATION: Remaining Replacements:16843296 Remaining Map Entries: 0 Remaining Updates: 0 READ DISC INFORMATION: Disc status: appendable Number of Sessions:1 State of Last Session: incomplete Next Track: 1 Number of Tracks: 2 READ TRACK INFORMATION[#1]: Track State: complete incremental Track Start Address: 0*2KB Free Blocks: 0*2KB Track Size:5908224*2KB READ TRACK INFORMATION[#2]: Track State: invisible incremental Track Start Address: 5908224*2KB Next Writable Address: 5908224*2KB Free Blocks: 5917952*2KB Track Size:5917952*2KB FABRICATED TOC: Track#1 : 14@0 Track#AA : 14@11826176 Multi-session Info:#1@0 READ CAPACITY: 11826176*2048=24220008448 root@bluray:/space/isotmp/test# Am Mi, 5.06.2013, 08:27, schrieb Thomas Schmitt: 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 day :) Thomas -- To unsubscribe, send mail to 709971-unsubscr...@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: i...@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: i...@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
Bug#709971: dvd+rw-tools: growisofs more then 1 Bluray, since Debian 7 speed collapses
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 21 Reading: time xorriso -scsi_log on \ -outdev /dev/srX \ -check_media use=outdev min_lba=0 max_lba=32 \ chunk_size=64s -- \ /tmp/xorriso_read_log 21 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 21 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-unsubscr...@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: i...@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: i...@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
Bug#709971: dvd+rw-tools: growisofs more then 1 Bluray, since Debian 7 speed collapses
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, driver code for particular busses and controller boards, ... lots of room to look for bugs. I will test a newer kernel asap. This will at least clarify whether it was a short living problem in the kernel. --- growisofs sr0info [...] xorriso sr1info: Strange. The first mediainfo reports Mounted Media: 41h, BD-R SRM which would match the media state that is used by libburn underneath xorriso. The second one is Mounted Media: 41h, BD-R SRM+POW which would match growisofs. But this from the first one does not look like the libburn results on my own BD burners: Disc status: complete Number of Sessions:1 State of Last Session: complete Number of Tracks: 1 READ TRACK INFORMATION[#1]: Track State: complete incremental Track Start Address: 0*2KB Free Blocks: 0*2KB Track Size:12219392*2KB Last Recorded Address: 5908367*2KB This is a closed medium (use xorriso -as cdrecord option -multi to keep it appendable if this is desired). But why does the drive report as track size the whole medium ? Well, the read size info looks ok: READ CAPACITY: 5908368*2048=12100337664 Probably the message by xorriso is a consequence of the Pseudo Overwrite formatting which growisofs applied. Hard to say whether this is sane or not. libburn does not do POW. The growisofs medium is appendable. But that does not mean it would have an incomplete session. (I will have to invest a BD-R for learning more about the doings of growisofs on these media.) Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709971: dvd+rw-tools: growisofs more then 1 Bluray, since Debian 7 speed collapses
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, remaining 5:55 RBU 100.0% UBU 50.0% 829612/12100028416 (68.6%) @3.1x, remaining 5:50 RBU 100.0% UBU 50.0% 8339554304/12100028416 (68.9%) @2.9x, remaining 5:46 RBU 99.9% UBU 50.0% 8384479232/12100028416 (69.3%) @3.0x, remaining 5:42 RBU 100.0% UBU 50.0% 8430682112/12100028416 (69.7%) @3.1x, remaining 5:37 RBU 100.0% UBU 50.0% 8472133632/12100028416 (70.0%) @2.8x, remaining 5:33 RBU 100.0% UBU 50.0% 8484552704/12100028416 (70.1%) @0.8x, remaining 5:33 RBU 100.0% UBU 50.0% 8508833792/12100028416 (70.3%) @1.6x, remaining 5:31 RBU 100.0% UBU 50.0% 8555134976/12100028416 (70.7%) @3.1x, remaining 5:26 RBU 100.0% UBU 50.0% 8600518656/12100028416 (71.1%) @3.0x, remaining 5:22 RBU 100.0% UBU 50.0% best regards Winfried -- ABK-Systeme GmbH, Am Weiher 1-3, D-63303 Dreieich Telefon: +49-(0)6103-98720 - Fax: +49-(0)6103-9872-22 E-Mail: i...@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: i...@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. +++ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709971: dvd+rw-tools: growisofs more then 1 Bluray, since Debian 7 speed collapses
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 $LW`.iso bs=64k count=1 Di 4. Jun 16:46:59 CEST 2013 1+0 Datensätze ein 1+0 Datensätze aus 65536 Bytes (655 MB) kopiert, 33,0877 s, 19,8 MB/s real0m33.228s user0m0.000s sys 0m1.160s root@bluray:/space/isotmp/test# same Work on two drives: root@bluray:/space/isotmp/test# date time dd if=$LW of=`basename $LW`.iso bs=64k count=1 Di 4. Jun 16:48:11 CEST 2013 1+0 Datensätze ein 1+0 Datensätze aus 65536 Bytes (655 MB) kopiert, 34,1167 s, 19,2 MB/s real0m34.258s user0m0.004s sys 0m1.144s root@bluray:/space/isotmp/test# root@bluray:/space/isotmp/test# date time dd if=$LW of=`basename $LW`.iso bs=64k count=1 Di 4. Jun 16:48:10 CEST 2013 1+0 Datensätze ein 1+0 Datensätze aus 65536 Bytes (655 MB) kopiert, 32,8995 s, 19,9 MB/s real0m33.040s user0m0.012s sys 0m1.120s root@bluray:/space/isotmp/test# on 3:root@bluray:/space/isotmp/test# date time dd if=$LW of=`basename $LW`.iso bs=64k count=1 Di 4. Jun 17:05:55 CEST 2013 1+0 Datensätze ein 1+0 Datensätze aus 65536 Bytes (655 MB) kopiert, 36,1785 s, 18,1 MB/s real0m36.325s user0m0.008s sys 0m1.112s root@bluray:/space/isotmp/test# root@bluray:/space/isotmp/test# date time dd if=$LW of=`basename $LW`.iso bs=64k count=1 Di 4. Jun 17:05:59 CEST 2013 1+0 Datensätze ein 1+0 Datensätze aus 65536 Bytes (655 MB) kopiert, 36,606 s, 17,9 MB/s real0m36.750s user0m0.008s sys 0m1.140s root@bluray:/space/isotmp/test# root@bluray:/space/isotmp/test# date time dd if=$LW of=`basename $LW`.iso bs=64k count=1 Di 4. Jun 17:06:03 CEST 2013 1+0 Datensätze ein 1+0 Datensätze aus 65536 Bytes (655 MB) kopiert, 36,9885 s, 17,7 MB/s real0m37.138s user0m0.024s sys 0m1.136s root@bluray:/space/isotmp/test# and on four: root@bluray:/space/isotmp/test# date time dd if=$LW of=`basename $LW`.iso bs=64k count=1 Di 4. Jun 17:07:26 CEST 2013 1+0 Datensätze ein 1+0 Datensätze aus 65536 Bytes (655 MB) kopiert, 32,8305 s, 20,0 MB/s real0m32.974s user0m0.012s sys 0m1.112s root@bluray:/space/isotmp/test# root@bluray:/space/isotmp/test# date time dd if=$LW of=`basename $LW`.iso bs=64k count=1 Di 4. Jun 17:07:28 CEST 2013 1+0 Datensätze ein 1+0 Datensätze aus 65536 Bytes (655 MB) kopiert, 37,0809 s, 17,7 MB/s real0m37.228s user0m0.016s sys 0m1.116s root@bluray:/space/isotmp/test# root@bluray:/space/isotmp/test# date time dd if=$LW of=`basename $LW`.iso bs=64k count=1 Di 4. Jun 17:07:30 CEST 2013 1+0 Datensätze ein 1+0 Datensätze aus 65536 Bytes (655 MB) kopiert, 32,6268 s, 20,1 MB/s real0m32.774s user0m0.016s sys 0m1.124s root@bluray:/space/isotmp/test# root@bluray:/space/isotmp/test# date time dd if=$LW of=`basename $LW`.iso bs=64k count=1 Di 4. Jun 17:07:33 CEST 2013 1+0 Datensätze ein 1+0 Datensätze aus 65536 Bytes (655 MB) kopiert, 32,9217 s, 19,9 MB/s real0m33.071s user0m0.012s sys 0m1.136s root@bluray:/space/isotmp/test# I don't think on the linux cache? Should I? now xorriso on one drive: root@bluray:/space/isotmp/test# time xorriso -outdev $LW -check_media use=outdev min_lba=0 max_lba=32 -- xorriso 1.2.2 : RockRidge filesystem manipulator, libburnia project. libburn : WARNING : Last session on media is still open. Drive current: -outdev '/dev/sr1' Media current: BD-R sequential recording Media status : is written , is appendable xorriso : UPDATE : 16 of 320001 blocks read in 3 s , 0.0xB xorriso : UPDATE : 8624 of 320001 blocks read in 4 s , 3.9xB xorriso : UPDATE : 18192 of 320001 blocks read in 5 s , 4.4xB xorriso : UPDATE : 27792 of 320001 blocks read in 6 s , 4.4xB xorriso : UPDATE : 37408 of 320001 blocks read in 7 s , 4.4xB xorriso : UPDATE : 47024 of 320001 blocks read in 8 s , 4.4xB xorriso : UPDATE : 56672 of 320001 blocks read in 9 s , 4.4xB xorriso : UPDATE : 66320 of 320001 blocks read in 10 s , 4.4xB xorriso : UPDATE : 76000 of 320001 blocks read in 11 s , 4.4xB xorriso : UPDATE : 85680 of 320001 blocks read in 12 s , 4.4xB xorriso : UPDATE : 95408 of 320001 blocks read in 13 s , 4.4xB xorriso : UPDATE : 105152 of 320001 blocks read in 14 s , 4.4xB xorriso : UPDATE : 114896 of 320001 blocks read in 15 s , 4.4xB xorriso : UPDATE : 124672 of 320001 blocks read in 16 s , 4.5xB xorriso : UPDATE : 134448 of 320001 blocks read in 17 s , 4.5xB xorriso : UPDATE : 144256 of 320001 blocks read in 18 s , 4.5xB xorriso : UPDATE : 154064 of 320001 blocks read in 19 s , 4.5xB xorriso : UPDATE : 163904 of 320001 blocks read in 20 s , 4.5xB xorriso : UPDATE : 173744 of 320001 blocks read in 21 s , 4.5xB xorriso : UPDATE
Bug#709971: dvd+rw-tools: growisofs more then 1 Bluray, since Debian 7 speed collapses
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 rejected ioctl is quite probably a matter of the kernel. Read Test with dd: same Work on two drives: and on four: Looks unsuspicious. I don't think on the linux cache? Should I? Depends on how much RAM your machine has. But the speeds of the already used drives did not increase from two-drive run to four-drive run. So i assume the cache did not buffer the whole 650 MB chunks. I see the :-[ CLOSE SESSION Bug every Time. It is said to be harmless (and was promised to get fixed in growisofs 7.1). Well, i though you might perhaps use BD-RE. if read [via ioctl(SG_IO)] is fast then writing [via ioctl(SG_IO)] is slow if writting is fast then read is slow Somehow simultaneously emitted ioctl(SG_IO) seem to disturb each other. are there hints for Kernel tuning? I am not a kernel expert (still on 2.6) and to my experience it is not easy to get support for kernels which are old enough for being in Debian Stable. You would probably have to install a current kernel and check whether the problem persists. We could watch libburn trying to perform read and write runs while being disturbed by other instances of libburn. Writing: xorriso -scsi_log on \ -as cdrecord -v dev=/dev/srX filename.iso \ 21 | tee -i /tmp/xorriso_write_log Reading: time xorriso -scsi_log on \ -outdev /dev/srX \ -check_media use=outdev min_lba=0 max_lba=32 -- \ 21 | tee -i /tmp/xorriso_read_log There will be measurements of execution time for each command. Like: READ(10) 28 00 00 00 01 60 00 00 20 00 16 ms The log will be very verbous and thus needs to be caught in a file. Maybe it is necessarey to replace 21 | tee -i /tmp/xorriso_write_log by /tmp/xorriso_write_log 21 in order to avoid slowdown by the mass of terminal output text. Probably you should send it directly to me and not to the Debian bug tracker. I will then report whether insight could be gained. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709971: dvd+rw-tools: growisofs more then 1 Bluray, since Debian 7 speed collapses
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 slow, then the ioctl() is most probably to blame. How are the drives attached to the computer ? Internal SATA ? eSATA ? USB (between computer and SATA) ? If USB: do SATA or eSATA work better ? What performance do you get from reading multiple BD media via the block device driver ? E.g. time dd if=/dev/srX bs=65536 count=1 What read performance do you get when reading via ioctl(SG_IO) ? E.g. time xorriso -outdev /dev/srX \ -check_media use=outdev min_lba=0 max_lba=32 -- What happens if you let some of your drives read while others write ? Probably it will not help to use a different burn program. Nevertheless, if you want to try: xorriso -as cdrecord -v dev=/dev/srX filename.iso You do not mention the known growisofs BD-R bug which causes the message at the very end of the burn run: :-[ CLOSE SESSION failed with SK=5h/INVALID FIELD IN CDB]: Input/output error If you are using BD-RE media, then try to write them via the block device time dd if=filename.iso of=/dev/srX bs=65536 Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#709971: dvd+rw-tools: growisofs more then 1 Bluray, since Debian 7 speed collapses
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 drives burn with aprox. 2.7x Speed, same like one drive would do. Now I installed Debian 7.0.0 amd64 and the speed drops below 1x if I burn more then one Bluray at the same time. For a Test I install Debian 7.0.0 i386 minimal without X11 and I get the same. regards Winfried root@bluray:/mnt/etc# lsscsi [0:0:0:0]diskATA ST31000524AS JC45 /dev/sda [1:0:0:0]cd/dvd HL-DT-ST BD-RE BH10LS30 1.01 /dev/sr0 [2:0:0:0]diskATA MAXTOR STM325082 3.AA /dev/sdb [3:0:0:0]cd/dvd HL-DT-ST BD-RE BH10LS30 1.01 /dev/sr1 [4:0:0:0]cd/dvd HL-DT-ST BD-RE BH10LS30 1.01 /dev/sr2 [5:0:0:0]cd/dvd HL-DT-ST BD-RE BH10LS30 1.01 /dev/sr3 -- System Information: Debian Release: 7.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 3.2.0-4-686-pae (SMP w/4 CPU cores) Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dvd+rw-tools depends on: ii genisoimage 9:1.1.11-2 ii growisofs7.1-10 ii libc62.13-38 ii libgcc1 1:4.7.2-5 ii libstdc++6 4.7.2-5 dvd+rw-tools recommends no packages. Versions of packages dvd+rw-tools suggests: pn cdrskin none -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
