[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

RE: mkisofs, cdrecord, 74min vs 80min CDROM media



Thanks for the reply.

I didnt know that RWs life span was around 1000 CDs.  I would be very
surprised if we havnt passed that already.  Is there a way I can "verify"
that it is a bad drive, aside from performing the same write to another
drive (<-- currently trying to allocate drive)?  What are the symptoms of a
bad drive?  I am getting kernal messages, "CAM SCSI" error messages which I
beleive are "timeouts" to read the device.  Though it will eventually read
the data fine, are there other messages I may expect?

Can you/anyone give some insight into how mkisofs performs the creation of
the image file?  What I am interested in is how it decides what
files/directories/data clusters it puts together in the begining and in the
end.  I ask because with the debug level I have on, I have noticed that it
puts my 2 problematic directories at the end of the image.  The directories
probably contain the most data (Megs).  Is there a way I can tell mkisofs
not to perform a sort or whatever clustering it does?  This would allow me
to eliminate it from my array of possible causes.

Thanks again,
Jason

> -----Original Message-----
> From:	J.A. Bezemer [SMTP:costar@panic.et.tudelft.nl]
> Sent:	Tuesday, February 06, 2001 6:01 AM
> To:	Allison, Jason A.
> Cc:	'debian-cd@lists.debian.org'
> Subject:	Re: mkisofs, cdrecord, 74min vs 80min CDROM media
> 
> 
> On Fri, 2 Feb 2001, Allison, Jason A. wrote:
> 
> >                                   Poblems we are seeing:
> >                                   Old problem:
> >                                   We has an 86 Meg tar file. The tar
> file
> > was being corrupted and I would get I/O errors when I did a tar tvf.
> > 
> >                                   Middle problems:
> >                                   Same tar problem as above.
> >                                   The directory logicaly after the tar
> file
> > is all messed up. Binary data in bourne shell scripts. Real weird. If I
> did
> > a strings
> >                                   load.sh, it wouldnt even show
> anything,
> > all binary data.
> > 
> >                                   Current problems:
> >                                   tar problem has seemed to go away.
> >                                   diretory after that, the files seem
> ok,
> > but uerf -R is reporting CAM SCSI errors while I do a file * on the
> > directory, and it
> >                                   takes forever to complete.
> > 
> >                                   Anyone who can give some insight into
> this
> > topic and/or has used these utilities before, I would greatly appreciate
> it.
> > 
> >                                   Possibilites:
> >                                   CD-RW going bad.
> 
> Likely. CD-RW drives are "supposed" to burn only some 1000 CDs. If you
> burn
> much, the drive wears off before the 1-year warranty expires and you'll
> get a
> free replacement ;-)
> 
> >                                   mkisofs having problems with such a
> large
> > file. I am going to test expanding that tar file out and recording then.
> > Though 2
> >                                   files logically before it are 56 and
> 62
> > Meg respectively.
> 
> Unlikely. On Linux you can "mount -o loop file.iso /mnt" to check the .iso
> before burning.
> 
> Also check the kernel error messages (supposing DigitalUX has those); if
> there are errors reported by the SCSI driver then you have a hardware
> problem
> (either the CD or the drive). 
> 
> 
> Regards,
>   Anne Bezemer



Reply to: