Re: Announcing cdrskin-0.4.4
Hi, i tested WRITE12 and Streaming bit on DVD-RAM. Up to the first bad spot on my test media writing runs with nearly nominal speed: Effective 1.8x with nominal 2x DVD-RAM. Without Streaming bit, WRITE12 and WRITE10 both perform at 0.8x effective speed. - To Giulio: Please get the newest cdrskin-0.4.5 development tarball http://scdbackup.sourceforge.net/cdrskin-0.4.5.tar.gz $ cdrskin -version ... Version timestamp : 2008.04.12.164930 or later timestamp. Next time you have a BD-RE formatted with spare area please try a write run with these options: $ cdrskin stream_recording=on --allow_untested_media - Observations with DVD-RAM: Interesting with normal writing is that the drive buffer bounces between 5% and 99% fill. One could well misinterpret this as a lack of i/o bandwidth. With Streaming bit, the drive buffer is always 99% full. The first reproducible bad spot (after 75 MB) makes both write variants quite unbearable. The drive gnaws a while, plonks, and does that again several times before going on with writing. If this happened with Streaming bit then the media produces lots of media error entries in /var/log/messages when trying to read sequentially over the bad address. With WRITE10 the same image and media are readable and verificable afterwards. But writing of 125 MB needed more than half an hour. This readability is not a statistically founded observation. I also had MD5 verification failures on DVD-RAM in the past. With two bad spots (one around 75 MB and one at 117 MB) it lasts 383 seconds to write 125 MB by WRITE12 Streaming. It lasts 2024 seconds with WRITE10. So the drive (Philips SPD3300L) and the media (Panasonic 2x DVD-RAM) together are not really recommendable. I will try to heal it by re-formatting in the next days. - Standards consideration: WRITE12 is not associated with the features comprising the profiles of DVD-RAM and BD-RE. So i cannot conclude from the presence and writeability of a DVD-RAM or BD-RE to the availability of WRITE12. It belongs to all other DVD+/- features, though. On my drive it obviously has an effect on DVD-RAM writing. Feature 107h belongs to DVD-RAM and BD-RE. It can indicate a Stream Writing bit which promises the Stream recording operation. That operation seems to be associated with WRITE12. Another method to find out about WRITE12 would be a test write to the start address before payload writing begins at the same address. I will have to think more about WRITE12. For now it is heavily experimental. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Announcing cdrskin-0.4.4
Hi, [dvd+rw-format] -format=full I think my kernel is too old, it exit after just 1 second: $ dvd+rw-format -format=full /dev/cdrom * BD/DVD±RW/-RAM format utility by [EMAIL PROTECTED], version 7.1. * 25.0GB BD media detected. * formatting 0.0|:-[ FORMAT UNIT failed with SK=5h/INVALID FIELD IN PARAMETER LIST]: Input/output error $ This looks rather like dvd+rw-format and your drive do not agree on what is a proper FORMAT UNIT command. The kernel has only the role of transporting command and answer. This it seems to do fine. The problem could be about this line in dvd+rw-format.cpp: if ((formats[4+4]3)==2)// same capacity for already formatted Since the -ssa=none format 31h is the largest of all, you cannot get a 30h format of the same size. That capacity wish would be the invalid filed in the command. If you want to go back to a smaller format you will probably need to give an explicit -ssa=size. I read in dvd+rw-format.cpp : -ssa=default Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Announcing cdrskin-0.4.4
(i.e. no spare area) by dvd+rw-format option -ssa=none It might also be worth to check the impact of certification on write error detection. I.e.: -format=full I would propose to try both. It would be most economic to do -ssa=none first, because i would expect it to be the most likely to omit error detection on traditional WRITE10 (SCSI command 2Ah). With -format=full i would possibly expect that WRITE12 (command AAh) is needed. What is it with desire to bypass defect management? I mean I can perfectly understand Thomas's curiosity, but why would end-user such as Giulio want it off? So you say my time is so precious that I must have faster write at any cost, ... so I can have time to verify afterwards? But why not let drive do it during recording then? The time would be the same. The drive is in position to do better job and it makes perfect sense to let it. Indeed, if result of your checksum test fail, what options do you have? Try recording once again spending double your precious time? In BD-R case even discard media, which is pretty expensive, isn't it? So if your time is so precious to you, defect management is actually *saving* it for you. Not to mention money and *data* itself. The only reason to bypass defect management would be real-time recordings, but then it's likely to be a video recording when it's more important to keep recording, then to miss a second. For any kind of *storage* application, i.e. kind of applications we discuss here, bypassing defect management makes *no sense* *whatsoever*. There seems to be a WRITE12 experiment ready in dvd+rw-tools-7.1/growisofs_mmc.cpp Maybe Andy Polykov already knows more about that topic. Yes, commented out WRITE12 code in growisofs_mmc.cpp was used in a defect management bypass experiment in DVD-RAM. Its purpose was to satisfy curiosity, such as what would it take for *another* kind of application. Kind of application that would also have to handle so called enhanced defect management codes. It's not in production and I have no intention to put into production for reasons discussed above. A. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Announcing cdrskin-0.4.4
Hi, What is it with desire to bypass defect management? I mean I can perfectly understand Thomas's curiosity, but why would end-user such as Giulio want it off? I can squeeze some scenarios out of my phantasy. Like: 1 hour 40 minutes is too long for a backup window. Or: The media are perfect and never ever show any bad spot. But i agree that disabling defect management needs good reasons and skilled handling of the consequences. So you say my time is so precious that I must have faster write at any cost, ... so I can have time to verify afterwards? Wearing my scdbackup hat, i object the equivalence of hardware defect management and a verification which uses the same means as a future restore run. It's nice to know that the drive cares for error detection and spare block management. But it is not overly trustworthy. I evaluated DVD-RAM a few years ago and found them less reliable than DVD+RW (with my old LG drive). I used growisofs-6.0 and the original formatting which still is: formatted: 2236704*2048=4580769792 00h(800): 2236704*2048=4580769792 00h(800): 2295072*2048=4700307456 01h(800): 2226976*2048=4560846848 01h(800): 2217248*2048=4540923904 This obviously includes defect management reserves. At least it ran at 0.7x DVD speed. Today defect management worked, although terribly slow, where plain writing yielded a bad burn. Maybe it's also a matter of drive and firmware. But as backup programmer i need my own test or i cannot lean back and smile. So the argument that one cannot save time by disabling defect management depends on the use case. Your opinion wins in many of those cases, i confess. such as what would it take for *another* kind of application. I begin to ponder how i can convince the libisofs developers of having a defect list in the ISO formatter. Possibly they will call me insane. Good. I have a reputation to defend. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Announcing cdrskin-0.4.4
Thomas Schmitt wrote: Hi, What is it with desire to bypass defect management? I mean I can perfectly understand Thomas's curiosity, but why would end-user such as Giulio want it off? I can squeeze some scenarios out of my phantasy. Like: 1 hour 40 minutes is too long for a backup window. That I can accept, I was going to post something similar. Or: The media are perfect and never ever show any bad spot. That sounds like a fairy tale. But i agree that disabling defect management needs good reasons and skilled handling of the consequences. So you say my time is so precious that I must have faster write at any cost, ... so I can have time to verify afterwards? Wearing my scdbackup hat, i object the equivalence of hardware defect management and a verification which uses the same means as a future restore run. Agree, if you want trust you are going to verify the backup anyway. It's nice to know that the drive cares for error detection and spare block management. But it is not overly trustworthy. I evaluated DVD-RAM a few years ago and found them less reliable than DVD+RW (with my old LG drive). I used growisofs-6.0 and the original formatting which still is: formatted: 2236704*2048=4580769792 00h(800): 2236704*2048=4580769792 00h(800): 2295072*2048=4700307456 01h(800): 2226976*2048=4560846848 01h(800): 2217248*2048=4540923904 This obviously includes defect management reserves. At least it ran at 0.7x DVD speed. Today defect management worked, although terribly slow, where plain writing yielded a bad burn. Maybe it's also a matter of drive and firmware. I would say that the drives have been designed to make writing work, without adding cost to make them work *well*. The only obvious way to get the speed up is a full read after write head, which introduces several cost factors. These drives are being used out of their intended use pattern, and show it. The user has a choice of solutions, none really satisfactory. But as backup programmer i need my own test or i cannot lean back and smile. So the argument that one cannot save time by disabling defect management depends on the use case. Ideally a copy of the backup would be held for byte-by-byte verify, and bad spots (only bad spots) would be rewritten. That assumes that they CAN be written successfully eventually. All solutions are ugly. Your opinion wins in many of those cases, i confess. such as what would it take for *another* kind of application. I begin to ponder how i can convince the libisofs developers of having a defect list in the ISO formatter. Possibly they will call me insane. Good. I have a reputation to defend. Have a nice day :) Thomas -- E. Robert Bogusta It seemed like a good idea at the time -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
