> It's not a raw partition: mkisofs generates the RO iso9660 from a existing
> (usually ext2) filesystem, and outputs it where you want it to go.
>
> So really, when creating a "new" CD, you can cut down on the number of
> copies by
>
> 1) increasing the userland cdwrite buffer to 10mb (kills 2 right there)
> 2a) making a cdwriter module instead of requiring a seperate program
> or
> 2b) moving cdwrite into mkisofs... (probably the better solution)
That ain't gonna happen (moving cdwrite into mkisofs).
The mkisofs program is designed to be portable. It should run on
HPUX, AIX, Solaris, VMS (at least it did at one time), and a whole host of
other things. The cdwrite program is inherently non-portable by the very
nature of what it needs to do. Thus I don't want to merge the two
programs together.
The other point that many people seem to forget is that writing a
CD is *very* timing dependent. You *must* be able to guarantee that you
can maintain the required datarate to the writer for the entire duration
of the burn, and that the buffer on the writer itself is never emptied.
If you fail to keep the buffer filled, then the disc that you end up with
will make a handy drink coaster, but that's about it. If you assume that
the image you are burning is contiguous on disk, then it is easier to
guarantee that the datarate remain high enough for the writer - this was
one of the main technical reasons why mkisofs and cdwrite have remained
seperate.
I didn't catch the start of this thread, so I don't know what the
main motivation for this was.
-Eric