[svlug] k3b, to erase or not to erase
mark at weisler-saratoga-ca.us
Tue Apr 29 08:38:14 PDT 2008
On Saturday 26 April 2008 14:57:43 David Fox wrote:
> On Sat, Apr 26, 2008 at 6:39 AM, Skip Evans <skip at bigskypenguin.com> wrote:
> > Hey all,
> > I have two servers here that every morning at 3am
> > tar up and gzip all the sensitive stuff: client
> Well, how large is the data set? If it's small, I'd hazard a guess
> that somehow you've set up multisession on that cdrw and K3B is simply
> starting to write from where it left off, but I could be wrong.
> Prior to writing said CD, have you examined it to see what data (if
> any) is present on the disk? Seems to me that would be the first place
> to look to see if your data is getting written and you've got a good
> CD-RW longevity depends on a lot of factors. I have a few old reliable
> four-speed cdrw's (Fuji) that just seem to keep on kicking after
> having been written to a number of times. I have garden-variety
> DVD-RW's that I refer to as write once, read never or maybe' as the
> seem that they can never checksum correctly. For instance, when I was
> doing a video project a year or so ago, I just decided that I'd
> rather make sure my avi's were burned to good media rather than try
> those questionable DVD-RWs even though that meant that I'd not be able
> to reuse them for something else.
> Is there an upper limit on the number of writes CD-RW media are good
> for? That I don't know.
> svlug mailing list
> svlug at lists.svlug.org
I want to make a few comments about K3B and my experience using it. My
comments are not directly related to this thread or the advice previously
given in this thread. I will say that David Fox knows a lot about burning
CD's and has helped me learn at CABAL meetings.
While I appreciate having K3B it behaves in curious ways, at least to my mind.
For example yesterday I was preparing to burn an iso image to a CD. I put a
fresh, unused CD in my trusty external Plextor, started K3B and directed it,
among other things, to use DAO, verify the written data, and use the slowest
speed possible . I selected the image I wanted to burn and hit enter
whereupon I was presented a dialog box offering me the following choices:
1. Use the "default" setttings.
2. Use the "saved" settings.
3. Use the setting that were used for the last burn.
Well, clearly, none of these options was what I wanted. I had _just entered_
the parameters I wanted to use. I had not "saved" anything. This is poor
design of human interface because the choices were not correct or relevant to
my task at hand.
What did I do? I chose 'Use the "saved" settings' and it worked; i.e., it used
the parameters I had just entered and wanted.
What happened then? Well the write went pretty well and maybe the verify but
eventually K3B spit out the CD and said there was an error on writing (I
believe the last tract or sector or something). But K3B has trained me to be
skeptical of its comments and warnings so I used K3B to take the MD5 sum of
the newly created CD. The MD5 sum matched what the iso vendor said it was
supposed to be suggesting to me that the CD was correct and healthy. I then
took the MD5 sum using the command line and it again was correct. I concluded
that the CD was almost definitely OK and have used it several times since
with no apparent error.
I am making it a point to learn to use growisofs as a CLI tool and use K3B
 In learning to use K3B I made many coasters by allowing K3B to use its
default settings. K3B would happily make a CD and report it was OK but then
it would not, for example, boot in the case of a live CD. I eventually, with
some coaching that I very much appreciate from someone on this list, used the
lowest possible speed settings and this greatly improved the reliability of
K3B burns. On this burn speed issue, I had many attempted burns simply fail
with K3B reporting 'unknown error' and then found that slowing the speed
almost completely cures this problem.
The conclusion for me is that when using K3B I use DAO as a writing method and
the slowest speed possible. And I am wary of the human interface and
messages. Maybe this will help Skip in considering how to regard K3B
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.svlug.org/archives/svlug/attachments/20080429/dfd40d0c/attachment.bin
More information about the svlug