One of the machines in the MOAT racks, "naice2.nlanr.net", is equipped with a CD recorder. This document gives instructions on the basic uses of the CD-R.
In order to burn CD's on naice2, you'll need a user account on that machine. Talk to Hans-Werner to get an account set up. Your user account must also be in the group "cdwrite" in order to use the CD-R.
The machine with the CD recorder runs FreeBSD 3.0-R; it is a PII-450 with 256MB of memory. We use Jörg Schilling's excellent "cdrecord" package to write the discs.
The CD recorder itself is a Yamaha CRW-4416S, a SCSI-2 CD-R that is rather popular as a drive that works well with unix. It supports up to 4x-speed writing on CD-R's, 4x-speed writing on CD-RW's, and 16x-speed reading. The CD-R is mounted in the "left" of the two NLANR/MOAT racks in the SDSC machine room, and is in the third machine from the bottom.
Authoring CD's can be a complex and frustrating process. The options for data storage are more involved than with most computer media. Floppy disks, hard disks, and things like that are generally presented as an array of sectors available for writing; CD's are composed of sessions, which are in turn composed of tracks, which are composed of audio or data sectors in a variety of formats. The sessions each have a "table of contents", which can be linked together in various ways. If this is done incorrectly, the CD may read in some drives, but confuse the firmware of others; or some data may not be visible to some machines. CD's also have all sorts of esoteric things like subcode channels, pre-emphasis on audio tracks, lead-in and lead-out sectors, pregaps, and things like that.
This is not to say that hard drive internals are necessarily simpler than CD-R internals; just that they look simpler from the outside, since the user doesn't have to worry about anything besides the data.
Given that 1) CD-R media is cheap, 2) We have plenty of available hard disk space for assembling images, and 3) We're interested in burning bulk data sets, we can simplify life considerably by restricting ourselves to the "base case" of single-session, single-data-track writes of ISO9660 level 1 filesystems. A CD written that way is almost guaranteed to work in any CD-ROM drive under the sun whose optics are happy with the media, and the writing process itself is uniform and almost immune to operator error.
ISO9660 is a specification for a filesystem, and it is the format most computer data CD-ROM's are stored in. There are several "levels" of ISO9660; we'll concern ourselves with level 1. Level 1 ISO9660 filesystems can contain files and directories of files. The file and directory names are restricted to something similar to MS-DOS "8+3" filenames. The base file names can be at most eight characters long, and can contain ony the characters "0-9", "A-Z", and "_". A period seperates the base name from an optional extension, which can be up to three characters and composed from the same character set as the base name. Directory names may not contain an extension. ISO9660 level 1 filesystems also cannot contain directories more than eight levels deep.
There are several extensions to the ISO9660 filesystem to allow long filename information to be stored on the disc; the two we'll be using are "RockRidge" -- which can encode long filenames, file permissions, and things like symbolic links -- and "Joliet", which encodes file names. Unix systems generally recognize RockRidge extensions, and some of them can also use Joliet extensions; win32 systems recognize Joliet, but not RockRidge. We'll include both sets of extensions on our CD's so that they're usable by more systems.
Given that there are convenient ways of encoding long filenames, which are widely recognized, and that 8+3 filenames suck, we'll ignore the ISO9660 level 1 naming constraints completely; the filesystems will still be written with level-1-compliant filenames, but most systems will see only the long filenames. In case someone's OS is incapable of recognizing either the RockRidge or Joliet long filenames, a text file will be written recording the long filename associated with each truncated level 1 name. The filenames should still be kept sane, however, since the Joliet extensions used by win32 systems are limited to 64 character names, and win32 software may be confused by strange characters.