Answer: that depends on your writer. Modern ones should have a data-buffer of 1MB or such 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 will surely corrupt the CD; you
better check such processes are not started via
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 usally so low that it's impact isn't noticed.
If you're uncertain than 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
bash> 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.
Yes. The only filesystem that isn't reliable and fast enough for writing CDs 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 CDs.
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
bash> /sbin/mke2fs 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
cdrecordon empty_file (which is no longer empty) as if it were an iso9660-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).
Please get the packages "cdda2wav" and "sox", available from sunsite and it's mirrors:
cdda2wav enables you to get a specific interval (or a whole track)
from your audio CD and converts it into a .wav-file.
the wav-files back into the (audio-CD) cdda-format so it can be written to
the CD-R using
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. */
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 seperate CD-ROM drive. By issuing the command
cdwrite -v -D /dev/sgc --pad -b $(isosize /dev/scd0) /dev/scd0 or 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
/dev/sgc to the CD-R.
Second case: you don't have a seperate CD-ROM drive. You have to use the writer to read out the CD-ROM in this case:
dd if=/dev/scd0 of=cdimage bs=1c count=`isosize /dev/scd0`
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. But you need to patch the kernel and recompile it. For further details see
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 CDs for reading. Example-entry for /etc/fstab:
/dev/scd0 /cdrom iso9660 ro,user,noauto 0 0