Date: Tue, 20 Oct 1998 13:58:39 +1000 From: "John Saunders" <john.saunders@scitec.com.au> To: <freebsd-current@FreeBSD.ORG> Subject: RE: packet writing Message-ID: <003101bdfbdd$ebed17d0$6cb611cb@saruman.scitec.com.au> In-Reply-To: <199810192330.RAA26343@panzer.plutotech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > cdrecord-1.6 documents an "experimental" packet writing interface. Can
> > someone clue me in as to what this is and the advantages/drawbacks of
it?
> > All I've heard about it is my cousin's rant about dragging and dropping
> > to the CD in lose9x <G>
>
> I dunno anything about it.
Basically packet writing allows you to stop, then re-start, the
burn mid track. However when you do this you end up with a few
sectors of junk while the laser is stopping and starting.
You can then use this feature however you like. Most Windows
software are split into fixed packet length and variable
packet length methods. The variable packet length writes
data continuously until there is no more to write. The fixed
packet method breaks all writes up into packets equal to the
size of the CDR drives buffer. With fixed size packets you
can never underrun, with variable sized packets you can. With
fixed sized packets you end of with "junk" sectors mid file,
with variable length packets the "junk" sectors are between
the files.
However to make use of this you need a filesystem able to
deal with WORM like media. Each time a file is written or
modified a new copy of the file is written to the end of
the media. Then a new copy of the directory structure is
written to the end of the disk that links to the new file.
If a file is deleted then only the directory structure is
re-written. The "standard" filesystem for packet writing
is called UDF. The spec for it is available from the usual
standards bodies. However it's likely that a filesystem
supporting a WORM drive will work just as well.
> > I fail to see a good reason for an OS-specific in-kernel CD-R driver,
> > when the cdrecord package works on plenty of systems that have SCSI
> > generic devices (passthrough). Unless I am missing some advantage of
> > having CD burning code in the kernel, this strikes me as a horrible
> > duplication of effort. So, what am I missing and why is this a good
> > idea? :)
>
> Well, in many ways it is a duplication of effort. It would be
> nice to have
> the capability to write CD-RW and DVD disks incrementally through a
> filesystem-type interface. To do that, you'd need filesystem support
> (probably), but also driver-level support for writing to CDs or DVDs. My
> guess is that "packet writing" lets you write incrementally to CDs, and
> that your cousin's Win95 box is doing it through a filesystem type
> interface.
For packet writing you could probably get away with just
supporting SCSI3/mmc compatible drives. But unless there is
some ability to have a user space filesystems (like GNU Hurd)
then it will have to be in the kernel.
Cheers.
-- . +-------------------------------------------------------+
,--_|\ | John Saunders mailto:John.Saunders@scitec.com.au |
/ Oz \ | SCITEC LIMITED Phone +61294289563 Fax +61294289933 |
\_,--\_/ | "By the time you make ends meet, they move the ends." |
v +-------------------------------------------------------+
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?003101bdfbdd$ebed17d0$6cb611cb>