On 11/2/07, Arno Lehmann <[EMAIL PROTECTED]> wrote:
>
> 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 :-)
Ok, now I don't feel as badly about asking a painful question!
> ... 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).
...
> > 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).
...
> > 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
# 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?
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 (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 and a lot of talk about
"which format will win" (but mostly in the context of consumer video and
entertainment). 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?
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 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, and why
not promote Bacula in the process? 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?
> 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?
> 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>
> >
> >
> -------------------------------------------------------------------------
> > 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
>
-------------------------------------------------------------------------
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
