RE: mkisofs, cdrecord, 74min vs 80min CDROM media
On Tue, 6 Feb 2001, Allison, Jason A. wrote:
> 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?
There are two critical moving parts in a CD-R/RW drive:
1) motor that spins the disk; if this wears out then the CD will appear to
write correctly, but the spinning gets a bit "shakey" so that the written
"dots" are sometimes a bit too long, sometimes a bit too short. It depends on
the drive _reading_ the CD if this is a big problem, some drives can
compensate better than others, mostly by trying many times and reducing the
reading speed. This commonly occurs first, and is probably your problem.
2) motor that moves the laser; if this wears out it can't follow the track
very well. This will produce a "track following error" during writing, and
cdrecord will abort. This occurs "only" if the drive has been intensively
used for reading (instead of writing).
> 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.
AFAIK mkisofs sorts the contents of each directory strictly alphabetically,
diving into subdirectories according to their place in their parent, so first
/a/a/a, then /a/a/b, /a/b, /a/c/a etc. up to /z/z/z.
(And indeed, the farther from the center (i.e. at the end of the image) the
more effect the "shaking" of the motor has.)
Regards,
Anne Bezemer
Reply to: