Hello, 02.11.2007 23:17,, Hydro Meteor wrote:: > > On 11/2/07, *Arno Lehmann* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]>> wrote: > > Hi, > > 02.11.2007 16:28,, Hydro Meteor wrote:: > > On 11/1/07, *Arno Lehmann* <[EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > > <mailto:[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 :-) > > > Ok, now I don't feel as badly about asking a painful question!
Good, no need for bad feelings regarding what I did :-) > > ... 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 :-) > > > Great for you! Its always great if you can get paid for learning > (instead of paying tuition to the school or educator). Yeah, indeed. One of the benefits of my current work - I learn something new every day :-) (Also from all of you here on the list :-) > ... > > 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. > > > Thank you, that is quite noble to do (because not everyone is going to > use DVD+RW that's for sure). Well, that's how this open source stuff works best, in my opinion. You take from it, and you give back to it whenever you get a chance to. > ... > > 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 :-) > > > For a moment I thought my eyes went buggy and I had made a mistake in my > assertion, but since you also found that "astonishing" I thought I'd > double check. Yep, here it is: > > http://www.bacula.org/rel-manual/DVD_Volumes.html#SECTION002740000000000000000 I could even fix this myself, but I have really almost no grasp of the way the manual is edited in its source form, so I'd prefer it if someone else fixed this :-) > # Bacula only accepts to write to blank DVDs. To quickly blank a > DVD+/-RW, run this command: > > dd if=/dev/zero bs=1024 count=512 | growisofs -Z /dev/xxx=/dev/fd/0 > > Then, try to mount the device, if it cannot be mounted, it will be > considered as blank by Bacula, if it can be mounted, try a full > blank (see below). > > > Based on this email thread, the line of interest should be corrected to > state: > > dd if=/dev/zero bs=2048 count=512 | growisofs -Z /dev/xxx=/dev/fd/0 > > I think this is an important correction to make especially for people > who are not familiar with writing to optical media with low level > command line tools. What is the proper procedure to kindly ask Kern to > update this for a future revision of the Bacula User's Guide? Just send him an email with a short pointer to you last mail. I think we should have our assumption confirmed by someone more in-depth with optical storage media, though. Anyone? > Also, I think it might help to distinguish (for emphasis purposes) > between "mount" in a Unix or Linux shell and "mount" in the context of > the Bacula Console. This had confused me and it took some time for it to > sink in Hmm... difficult. The commands are named as they are because it describes what they do best, in comparison to unix systems mount. The examples, in my opinion, are quite clearly distinguishing between OS mounts and Bacula mounts. If you see possible improvements, feel free to post them here - I'm sure they will be discussed and, if no-one disagrees, they would be changed in the manual. > (so I what I was doing accidentally was trying to issue > command-line Linux bash shell "mount" commands ... thanks to Dave Green > in New Zealand for pointing this out to me in off-list email threads > recently). > > > # 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. > > > That's too bad. Well, there is already a great deal of confusion in the > market it seems about BluRay and HD DVD formats At least from reading the web pages I mentioned - especially the chalmers.se one - I assume that BD and HDDVD are handled similarly to writeable DVD media from an application softwares point of view. The details will probably hold many surprises :-) > and a lot of talk about > "which format will win" (but mostly in the context of consumer video and > entertainment). For storage of "plain" data, I think this discussion will be irrelevant. Luckily. > I can only imagine it will be like pulling teeth to get > proper documentation on the low-level structures of these more advanced > optical disc media formats, true? I think it's quite well documented, but how to get the devices to correctly write these media is most probably less well documented. I don't think reading the ATA specs gives you all the necessary detail, and it certainly gives you examples of API calls (API between drive firmware and application program, i.e. the ATA commands you have to send, the expected results, and how to do this with linux' libata stack). > This brings up an idea. Perhaps we as members of the Bacula community > can put some pressure on these BluRay (Sony?) and HD DVD manufacturers > and format "authoritarians" I seriously doubt that - they are mainly focusing on the video business, I think. > (I forgot who mostly behind doing HD DVD -- > is it Panasonic and Toshiba?) and they really ought to be thinking about > how they can promote their higher density optical discs for storing data > and for serious backup processes ranging from home networks to > enterprises, They guys working on the dvd+rw-tools, cdrecord, and the like would be the ones who would need that support. They'd probably like to know that there is a wide user base of their programs, though. But as I don't know how these tools are developed, I have no idea if there's an actual interest in this sort or moral support. > and why not promote Bacula in the process? That's something I always like :-) > It could > actually end up being a great PR move for both Bacula and the > manufacturers (Sony, Toshiba, et al) especially since a lot of these > large companies lately are interested in being seen as socially > responsible and being aligned with good open source projects, no? It > would be great to have some Bacula advocates from theses companies I > think (and ask them to participate in the community by assisting with > some clearer documentation and semantics)? Or is that a bad idea? I don't think it's a bad idea per se, but I think we are not in a position to achieve much here. I'm assuming the teams developing the tools using the hardware have some contacts in the manufacturing companies. I don't know how much support they receive from them, though. Looking at the chalmers site, I find that dvd+rw-tools were supported by some of the manufacturers, though. The most difficult problem might be that even major manufacturers like to have hardware and firmware developed by third parties today, and quite often don't have the detailed information that would be needed themselves, or are not allowed to effectively publish it by giving it to an open source project. Just look at suns program to make hardware documentation freely available: There are many components where sun has to do a lot of work on legal issues with the original developers and IP holders of them. If, for example, the developers of dvd+rw-tools could state that some really big company would use a large number of a certain brand of BluRay writers for backups they were certified to work with the software, that might help. A number of unrelated small users will not be very important besides the media business, or the game console manufacturers, where most of these devices are used today. > > 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... > > > But I wonder if this changes for the higher density beasts (BluRay, HD)? > Are there any Bacula sys admins using BluRay or HD? As the basic filesystem on BD and HDDVD is quite similar to what's used on DVD natively (UDF), IIRC, the industry consortiums defining these disk formats will most brobably have used that as a base. Then it wouldn't make much sense to change the native block size of the media. Arno > > 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. > > > Right on! > > -H > > Arno > > > Cheers! > > > > -H > > > > Good luck! > > > > Arno > > > > -- > > Arno Lehmann > > IT-Service Lehmann > > www.its-lehmann.de <http://www.its-lehmann.de> > <http://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> > > <mailto: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 > <mailto:Bacula-users@lists.sourceforge.net> > > https://lists.sourceforge.net/lists/listinfo/bacula-users > <https://lists.sourceforge.net/lists/listinfo/bacula-users> > > -- > 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/ > <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 > > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > 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
