Message-ID: <3970E332.78729F63@ece.gatech.edu>
Date: Sat, 15 Jul 2000 18:18:26 -0400
From: Charles Wilson <cwilson AT ece DOT gatech DOT edu>
X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: opendos AT delorie DOT com, b52g AT usa DOT net
Subject: Re: UDF support in NWCDEX?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: opendos AT delorie DOT com

> > Charles Wilson <cwilson AT ece DOT gatech DOT edu> wrote:
> > OpenDos list:
> 
> > Does the CD redirector in OpenDos, NWCDEX, support the UDF format used
> > by CD-RW and DVD?
> > I'm trying to build a boot floppy that can access CD-RW disks (packet
> > write, UDF format).
> 
> Linux 2.3 supports it, but as far as I know no DOSes can handle UDF.
> Even Windows 95 can't without being modified.
> 
> I've always considered packet writing a silly idea anyway since UDF wastes a
> lot of space, about 10-15% of the disk IIRC.

Well, yes and no. ext2 wastes space for the superblocks and inode lists.
FAT wastes space for the multiple FAT copies, and then there's the
cluster-size problem (slack). Every form of organized storage has
overhead. 15% is excessive, I'll grant you. 

However, the reason is because UDF uses packets (each with their own
overhead) and the packets are fixed-size -- leading a problem similar to
the 'cluster-size' problem in FAT. 

Each packet has overhead -- just like DOS clusters reserve some number
of bytes for a pointer to the next cluster in the file. Of course,
packet overhead is larger than cluster overhead, but that has to do with
the physics of the laser and the CDRW media itself, I think. (You don't
pay these costs when doing disk-at-once writing -- but without packet
writing you can't use the CDRW as a 'normal' storage device like a hard
drive).

You could use variable length packets, which work okay on a write-once
medium, but keeping track of writes/deletes of millions of variable
length packets is just too painful -- and would slow down
writes/rewrites/reads to unacceptable levels. AND would require a large
table somewhere on the disk where you keep track of all that information
-- which is more overhead! :-)

--Chuck