Hi, 02.11.2007 16:28,, Hydro Meteor wrote:: > On 11/1/07, *Arno Lehmann* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: ... > Sorry to ask a painful question :-)
It actually didn't hurt, it just reminded me that sometimes I try to work on things without actually understanding enough of the problem :-) > ... but in your answer, I have many > more times appreciation of what you must have gone through (the pain and > the suffering). It wasn't that bad, actually. It took some time, but I did learn a lot, after all, I got paid for that work :-) ... > In the end, I didn't understand anything :-) , > > > heh! I can understand -- there's lots to collect. Also, you probably > started this project before you would have the benefits of community > organized information sources such as Wikipedia, true? Well, kind of... there was information available, but I think I was slowed down a bit by not really understanding the technological issues. I might have had better results with more time (rather obvious) or if I restricted my attempt to get results to only one type of media (like DVD+RW) but, contributing to an open source project, I decided that, whatever I came up with, should be as universally usable as possible. ... > Arno and friends, it was the dvd+rw-mediainfo (running in Debian as the > Guest Operating System under Parallels as a virtual machine) that gave > me the info which then gave me hints and clues. For example, I am using > TDK 4.7 GB DVD+RW discs. When I rand the dvd+rw-mediainfo after > inserting a new TDK DVD+RW out of the spindle, I got the following output: > > $ dvd+rw-mediainfo /dev/cdrom > > > INQUIRY: [MATSHITA][DVD-R UJ-85J ][FDSA] > GET [CURRENT] CONFIGURATION: > Mounted Media: 1Ah, DVD+RW > Media ID: PHILIPS/041 > Current Write Speed: 4.0x1385=5540KB/s > Write Speed #0: 4.0x1385=5540KB/s > Write Speed #1: 2.4x1385=3324KB/s > Speed Descriptor#0: 01/2295103 [EMAIL PROTECTED]/s > [EMAIL PROTECTED]/s > Speed Descriptor#1: 01/2295103 [EMAIL PROTECTED]/s > [EMAIL PROTECTED]/s > READ DVD STRUCTURE[#0h]: > Media Book Type: 00h, DVD-ROM book [revision 0] > Legacy lead-out at: 2295104*2KB=4700372992 > READ DISC INFORMATION: > Disc status: blank > Number of Sessions: 1 > State of Last Session: empty > "Next" Track: 1 > Number of Tracks: 1 > READ FORMAT CAPACITIES: > unformatted: 2295104*2048=4700372992 > 26h(0): 2295104*2048=4700372992 > READ TRACK INFORMATION[#1]: > Track State: blank > Track Start Address: 0*2KB > Free Blocks: 2295104*2KB > Track Size: 2295104*2KB > READ CAPACITY: 0*2048=0 > > > The output correctly identifies my Apple Xserve's OEM DVD burner (their > "SuperDrive") as being from Matshita (I think a division of Panasonic). > > It was in this output that I found a useful hint -- to use a block size > of 2048 bytes instead of the typical (and recommended in the Bacula > User's Guide) of 1024 bytes, as the value of the bs= option in the dd > command, like this: That is really astonishing... as far as I recall, all DVD and CD technologies use 2k block sizes, and I believe this is required by the standards they follow. So, 2k blocks for dd should have been used from the start :-) > # dd if=/dev/zero bs=2048 count=512 | growisofs -Z /dev/cdrom=/dev/fd/0 > > > Whereas 1024 bytes was not working for me (and thus my only resort was > to blank or "nullify" with ASCII NULL characters the entire disc), the > command above worked just perfect and only took about one minute to > de-ice, The reason nobody before seemed to notice that might be that different drives handle this stuff differently - that seems to be part of the problems with optical media: the drive manufacturers really don't implement a strict standard, they implement something that works most of the time but is poorly documented. > with this output: > > Executing 'builtin_dd if=/dev/fd/0 of=/dev/cdrom obs=32k seek=0' > 512+0 records in > 512+0 records out > 1048576 bytes (1.0 MB) copied:-[ GET EVENT failed with > SK=5h/ASC=24h/ACQ=00h]: Input/output error > /dev/cdrom: pre-formatting blank DVD+RW... > , 0.127611 seconds, 8.2 MB/s > /dev/cdrom: "Current Write Speed" is 4.1x1352KBps. > builtin_dd: 512*2KB out @ average 0.8x1352KBps > /dev/cdrom: flushing cache > /dev/cdrom: stopping de-icing > /dev/cdrom: writing lead-out > > > I wonder, does the manufacturer of the DVD+RW media (in this case I > think the TDK brand name is owned by Philips), determine the block size > (2048 bytes)? I suppose so. It would be useful to compare to other > DVD+RW disc brands such as Sony, Verbatim, etc. I haven't got a DVD writer attached at the moment, but I'm quite sure you'll find 2k blocks everywhere... > Thank you for pointing out the useful command-line tool dvd+rw-mediainfo > command (being that I spend more time on Mac OS X and not as much on > Linux, I wasn't familiar with it). I think it would be valuable to add > my discovery to the Bacula DVD Tips web page maintained by Richard > Mortimer and would it also be valuable to incorporate into the Bacula > Wiki? Speaking of which (as I'm cc'ing Richard), would it perhaps not be > easier to move the Bacula DVD Tips web page into the Bacula Wiki (or > Richard would you prefer to maintain that separately)? Oops, I completely forgot about Richards site :-) I'll have to bookmark it again and re-read it... anyway, I think Richard would like to add your findings. Moving his information into the Wiki is probably best done using a pointer to his site - last time I looked, Richard's site was in a shape that didn't require heavy user contribution. Like, it's more or less complete, might benefit from information like you supply, but it's probably a good idea to work together with Richard when including it. Arno > Cheers! > > -H > > Good luck! > > Arno > > -- > Arno Lehmann > IT-Service Lehmann > www.its-lehmann.de <http://www.its-lehmann.de> > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > <mailto:Bacula-users@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/bacula-users > <https://lists.sourceforge.net/lists/listinfo/bacula-users> > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Bacula-users mailing list > Bacula-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bacula-users -- Arno Lehmann IT-Service Lehmann www.its-lehmann.de ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
