CDrecord builds, but with errors

[Aaron Sakovich]

I'm trying to make a CD on my rx2600. I've been able to create it, but after I mount the freshly burned CD, I see the following error in my $Show Device DQA0: /Full output:

Volume Status: ODS-2, subject to mount verification, allocation inhibited
because of error on bitmap, file high-water marking, write-back caching
enabled.

I can mount the CD on my rx2620 (I've yet to try it on another i64), but I am unable to mount it due to errors on the disk when I try it on an Alpha.

First time through, I made sure I was creating the LD in multiples of 4 blocks. After a couple tests, I've now tried doing it in a multiple of 96 blocks (based on some now-dated info that I used to build LD volumes for my old CD disk image creation tools). I still get the same "allocation inhibited" error.

Any ideas what's causing this? What can I do to get past this problem?

[Steven Schweda]

It might help to know exactly how you're
creating your disc image, what you're using
for cdrecord, how you're using it, which sort
of CD-writing drive and media you're using,
and so on (and on, ...). There seems to be
more than one variable here.

If you read the CD using COPY or readcd (or
some similar, low-level program) to get an
image file from the disc, how does it compare
(BACKUP /COMPARE is handy) with the original
image file which you used to make the disc?

> [...] due to errors [...]

Are these _secret_ errors, or are you
offering clues? If different drives can't
read the disc reliably, that fact might be
trying to tell you something. Unless you're
carrying the same CD drive from box to box,
I'd worry more about the drives than I would
about the Alpha-IA64 diifferences.

[Hoff]

Your title says "cdrecord builds". Are you building your own copy of cdrecord source code here?

What OpenVMS I64 version?

One of the other locals here has an early port of cdrtools-2_01_01a22 around, but I don't know that he wants everybody grabbing copies quite yet. (He had sent private email.)

There's an integrated version of cdrecord in OpenVMS starting at V7.3-1, and there's a new recording subsystem in OpenVMS V8.3; the COPY /RECORDABLE_MEDIA verb. The integrated version of cdrecord isn't the newest, but it works with the drives HP has been providing.

As for the source disk, did you initialize the disk with a cluster factor that is a multiple of four?

What does ANALYZE /DISK have to say about the created disk?

There are some latent tools around that verify the source partition and the created disk, these are first available in V8.3.

There's a recording document posted over at: http://h71000.www7.hp.com/wizard/wiz_9820.html

I have emailed you a document I'm working on. It describes how to record CD and DVD on OpenVMS -- it's a work in progress, but might address your questions. When it and a side issue are resolved and ready, I'll serve it up for anyone.

Stephen Hoffman
HoffmanLabs

[Heuser-Hofmann]

Aaron,

cdrecord on Itanium just works fine. So there seems to be a wrong selection of the options you choose. Could you tell us how the command line looks like?

Eberhard

[Aaron Sakovich]

I am running on i64 OV v8.2-1, and am using the included CDrecord command procedure in Sys$Manager, and the version of CDrecord.exe that is bundled from HP.

As stated in my OP, I did create the CD container file as a multiple of 4 blocks, and then subsequently as a multiple of 96 blocks.

I've now been able to test the CD created with a 96 block multiple on another rx2620, and it mounts and I can read the contents. I still see the aforementioned error in the Volume Status.

I just mounted this same CD on an Alpha, and I can mount and read it -- WITHOUT any error, including no "error on bitmap".

Now the question is, is this a factor of reading the CD on an AlphaServer 4100 vs. DS10/AS500/AS800/VAX4100, or the fact that I used a 96 block multiple instead of 4? More testing is needed unless someone else knows the answer!

[Hoff]

I've been recording these disks on VAX, Alpha and I64 for a gazillion years...

As a test, create a partition of 1,200,000 blocks or 1,400,000 blocks, and use a cluster factor multiple of four to initialize it.

There are two multiples of four lurking around these operations, the total partition size for the LD or VD device, and the disk volume cluster factor for the INITIALIZE command. (Also look at using /ERASE on the initialization processing, as this reduces the exposure to disk scavenging in the resulting optical media.)

There's a little wrinkle in the last sector, depending on the device.

The bitmap can also get involved if you're using DVE; if dynamic volume expansion is enabled. Also check your ECOs.

[Aaron Sakovich]

I've burned 2 CDs now with a blocking factor of 96, and both have been mountable on multiple systems in spite of the fact that they show the error in the Volume Status.

Reading my source code for a proprietary solution I wrote to CD recording prior to 7.3, I found the following reference regarding the 96 block size:

http://www.djesys.com/vms/cdrom.html#creld

Is this still pertinent with the version of CDrecord on 8.2-1? The logic and math David's putting forth seems reasonable and should be independent of any OS version, I would think.

These may be 2 different issues -- the bitmap may just be corrupted for any number of reasons and may simply be coincidental, but the blocking factor of 4 vs. 96 may be why I couldn't mount the CD on older Alpha CD ROM drives. Or this could be an artifact of the CD-R drive I'm using (TEAC DW-224E, rev C.0B).

I freely admit that I'm speculating here, but my goal is to eliminate variables to find the culprit. I've still got more testing to do...

[Hoff · Accepted solution]

That Teac looks like one of the HP integrated drives (IIRC), and it should work.

The geometry-related disk volume issues have mostly died a not-so-noisy death within the I/O stack. There are still pieces there that have those values and there can be some grumpy error reports -- that ATW topic I pointed to has some details -- but for the most part the geometry requirements are about as gone as could have been reasonably managed. There's one other oddity around the last block and the sector fill, and that's been hit-or-miss depending on the behavior of the particular drive and the requested size. (It was widely discussed in InfoServer Scribe days.)

The Dynamic Volume Expansion (DVE) and Dissimilar Device Shadowing (DDS) projects were arguably the end-point of the geometry "fun"; it was that work that really pushed the geometry genie back into its bottle.

There's one other wrinkle here that just occured to me: the OpenVMS I64 disks will default to having a GPT. Try that INITIALIZE with /ERASE /CLUSTER=n*4 /NOGPT and whatever else you were using.

In particular, older OpenVMS Alpha (eg: V7.3-2 and prior) won't know what to do with a disk with a GPT, and might well complain some.

[Aaron Sakovich]

Check on the TEAC being the HP installed drive.

Darn, I missed the section on the GPT before, and I just checked the help on Init/GPT -- that does sound like a prime candidate, although all the symptoms don't fit the pattern right now. I should have the CDs in hand early next week so that I can do some more testing on them (I'm burning them 1000 miles away and having them shipped here. Yes, it's not terribly efficient! And this is also the reason I've not been able to do an Anal/Disk -- they're in the mail on their way to me.)

Thanks for your help, Hoff. I'll be back on this topic next week.