Answer: that depends on your writer. Modern ones should have a data-buffer of 1MB or larger and can live 1-2 seconds without data. See the manuals or ask your manufacturer if you want to know the details. Regardless of the size of those data-buffers you must guarantee a constant throughput of 300kb/s or 600kb/s in the long time run.
Disk intensive processes such as updating the locate-database
lower the maximum flow-rate may corrupt the CD; you
better check such processes are not started via cron, at or
anacron while you burn CD-Rs.
On the other hand, people reported that they compiled a kernel while burning a CD without a glitch. Of course you need a fast machine for such experiments.
Fragmentation is usually so low that it's impact isn't noticed. However, you can easily construct pathological cases of fragmentation, which lower the throughput of your harddisks under 100 kbyte/second. So don't do that. :-)
Yes, files on a harddisk get fragmented over the years. The faster, the fuller the filesystem is. Always leave 10% or 20% free space, and you should run fine with respect to writing CD-Rs.
If you're uncertain then look at the messages printed while booting, the percentage of fragmentation is reported while checking the filesystems. You can check for this value with the very dangerous command
shell> e2fsck -n /dev/sda5 # '-n' is important!
[stuff deleted - ignore any errors]
/dev/sda5: 73/12288 files (12.3% non-contiguous)
In this example the fragmentation seems to be very high - but there are
only 73 very small files on this filesystem (used as /tmp) so the
value is _not_ alarming.
There is an experimental utility called e2defrag to defragment extended-2 filesystems. The current version does not work reliable enough yet, to use it even for private environments. If you really want to defragment your filesystem, make a backup copy (better: two copies), practise restoring the data, then create a new filesystem (will destroy the old) and restore the data. In a few words, this is currently the safest technique.
Yes. The only filesystem that isn't reliable and fast enough for writing CD-ROMs from is the network filesystem (NFS).
I'm using UMSDOS myself to share the disk-space between Linux and DOS/Win on a PC (486/66) dedicated for writing CD-ROMs.
Yes. You can put any filesystem you like on the CD. But other operating systems than Linux won't be able to deal with this CD.
Here goes the recipe:
dd if=/dev/zero of="empty_file" bs=1024k count=650
shell> /sbin/mke2fs -b 2048 empty_file
empty_file is not a block special device.
Proceed anyway? (y,n) y
mount -t ext2 -o loop=/dev/loop1 empty_file /mnt
cdrecord on empty_file (which is no
longer empty) as if it were an ISO-9660-image.If you want to make an entry in /etc/fstab for such a CD, disable
the checking of it, e.g.:
/dev/cdrom /cdrom ext2 defaults,ro 0 0
The first 0 means "don't include in dumps", the second (=important) one means "don't check for errors on startup" (fsck will fail to check the CD for errors).
There are several software packages available. The newest one is "cdpranoia" and can be downloaded from
http://www.mit.edu/afs/sipb/user/xiphmont/cdparanoia/index.html
Or you want to try the combination of "cdda2wav" and "sox", available from sunsite and it's mirrors:
ftp://sunsite.unc.edu/pub/Linux/apps/sound/cdrom/cdda2wav0.71.src.tar.gzftp://sunsite.unc.edu/pub/Linux/apps/sound/convert/sox-11gamma-cb3.tar.gz
cdda2wav enables you to get a specific interval (or a whole track)
from your audio CD and converts it into a .wav-file. sox converts
the wav-files back into the (audio-CD) cdda-format so it can be written to
the CD-R using cdrecord. You don't necassarily need sox if
you use a recent version of cdrecord, because it has built-in
support for .au and .wav files.
The file drivers/scsi/scsi.c contains the information
/*
* Usage: echo "scsi add-single-device 0 1 2 3" >/proc/scsi/scsi
* with "0 1 2 3" replaced by your "Host Channel Id Lun".
* Consider this feature BETA.
* CAUTION: This is not for hotplugging your peripherals. As
* SCSI was not designed for this you could damage your
* hardware !
* However perhaps it is legal to switch on an
* already connected device. It is perhaps not
* guaranteed this device doesn't corrupt an ongoing data transfer.
*/
Please note that this should only be used if your add SCSI-devices at the end of the chain. Inserting new SCSI-devices into an existing chain disturbs the naming of devices (directory /dev) and may destroy the complete content of your harddisk.
Yes. But you should be aware of the fact that any errors while reading the original (due to dust or scratches) will result in a defective copy.
First case: you have a CD-writer and a separate CD-ROM drive. By issuing the command
cdrecord -v dev=3,0 speed=2 -isosize /dev/scd0
you read the data stream from the CD-ROM drive attached as
/dev/scd0 and write it directly through the SCSI-device with ID 3
to the CD-R.
Second case: you don't have a separate CD-ROM drive. You have to use the writer to read out the CD-ROM in this case:
dd if=/dev/scd0 of=cdimage
This command is equivalent to the result of mkisofs, so you
should procede as described in chapter 3. Please note that
this method will fail on audio CDs!
Yes. Newer Kernels (2.0.36 and the upcoming 2.2) have built-in support for the joliet format. Remember you have to use both options in your /etc/fstab: the keywords iso9660 and joliet (later is really an extension). For more details, see http://www-plateau.cs.berkeley.edu/people/chaffee/joliet.html.
Just as you do with regular CD-ROM drives. No tricks at all. Note that you have to use the scd-devices (SCSI CD-ROM) to mount CD-ROMs for reading. Example-entry for /etc/fstab:
/dev/scd0 /cdrom iso9660 ro,user,noauto 0 0
Use bzip2 instead of any other compressor like gzip or
pkzip. It will save you up to 30% of disk-space for larger
(>100kb) files. You can download it from
http://www.muraroa.demon.co.uk/
Instead of writing a true audio-CD, you can optionally convert your wav-audio-files into mp3-audio-files and store them on a ISO-9660 filesystem as regular files. Usually MPEG III gives you a compression of 1:10.
Of course, most CD-players are not able to read files... this is the drawback. On the other hand, why not running the music for your next party from harddisk? 18 Gbyte are enough for 3000-4000 titles. :-)
A software MPEG III-encoder is available from
http://www.stud.ifi.uio.no/~larsi/other/8hz-mp3-cheng.tar.gz
A MPEG III-player is available from
http://homepages.uni-tuebingen.de/student/michael.hipp/mpg123/
For recorded speech, you may want to try to reduce its size using
shorten or "GSM lossy speech compression":
ftp://svr-ftp.eng.cam.ac.uk/pub/comp.speech/http://kbs.cs.tu-berlin.de/~jutta/toast.html
You must have an 1.44 MB bootable floppy-disk. Create an exact image of this floppy-disk by issuing the command
dd if=/dev/fd0 of=boot.img bs=18k
Place this floppy-image into the directory holding the collection of your files (or into a subdirectory of it, just as you like). Tell mkisofs about this file with the option '-b' and also use '-c'. For details read the file README.eltorito in the mkisofs-distribution.
An interesting application for a custom bootable CD is as a virus-safe DOS- or Windows-system. It saves you the money for the harddisks (if you have a network and use samba to put the user-data on a fileserver). However, this is purely theoretical as nobody reported an actual recipe to me.
Some details about the bootable RedHat CD-ROM is available from http://www.channel1.com/users/rodsmith/rhjol-technical.html.
There is an overlay-filesystem available for Linux, which is mounted over the CD-ROM and intercepts all writing operations. New and modified files are stored elsewhere, but for the user it looks like the CD-ROM is modified. For more information, see http://home.att.net/~artnaseef/ovlfs/ovlfs.html.
If that is not enough for your needs: wait for the UDF-filesystem to be supported by Linux or help developing it (see http://trylinux.com/projects/udf/.
Yes. However, it has been only tested with two writers yet. And you need a kernel patch for more buffers in the SCSI-generic driver ( ftp://ftp.fokus.gmd.de/pub/unix/cdrecord/alpha).
The german computer magazine "c't" had a list of tips regarding the blank CD-Rs in their november 1996 issue: