[svlug] k3b, to erase or not to erase

[Mark Weisler]

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
> backup.
>
> 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
> http://lists.svlug.org/lists/listinfo/svlug
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 [1]. 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 
less.
[1] 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 
messages.

-- 
Mark Weisler 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.svlug.org/archives/svlug/attachments/20080429/dfd40d0c/attachment.bin