--zhXaljGHf11kAtnf
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Tue, Aug 30, 2005 at 07:29:21PM -0700, Bill Studenmund wrote:
> > Note that we already have IOCTLs for synchronise cache. Maybe you could
> > reuse that ?
> 
> Yes, but that's only one call.

true, though one of the more important ones.

> > Yes; I think we should also allow writing though the raw or block device;
> > so we could allow writing using e.g. dd (instead of writing only though
> > the UDF filesystem).
> 
> Are you sure that these devices will support that? Perhaps I'm 
> overly-conditioned, but I have never looked to dd as a way to write CDs, 
> so I don't see why it should be a way to write UDF disks.

writing CD-R's with `dd' can be tricky but the current code will do it 
though i agree with Bill that i never looked at dd as a way to write CDs. 
The CD-R disc is also finalised after the dd which surprised me. Is this 
copying with `dd' and closing the disc after behaviour hard coded ?

> > > I've thought about implementing a /dev/mmc* device that is specific for 
> > > cd/dvd/bd recordables/rewritables since they are a special breed of 
> > > critters quite different from normal cd-rom/dvd-rom. Seperating mmc devices 
> > > from the generic `cd' devices also enables more targeted code to be 
> > > written. Code could also be simplified. How to use the detection framework 
> > > i haven't figured out yet though. What i've read indicates that Linux also 
> > > split off mmc devices from the older legacy CD driver.
> > 
> > How much code would this represent ? I don't know if it's really
> > worth it, and /dev/mmc vs /dev/cd could be confusing for users (not counting
> > the third-party packages that would need to be adapted to use both :)
> 
> Can't say here.
> 
> However my understanding is that UDF is designed to work with MMC devices. 
> As such, I don't think it's unusual to expect it to know about SCSI 
> commands, and to not work so well with non-SCSI/ATAPI devices.

UDF is designed to work on a wide range of optical devices like CD/DVD/BD 
but also non-sequential WORM like devices (rare critters) and has many 
references in the standard to things like sessions, tracks, reservations, 
sector type setup (CD-R/CD-RW), track types like BD-LOW not to mention the 
dreadfull DVD-R DL semantics with shifting logical sector. The UDF spec has 
specific requirements for each variation of CD/DVD/BD media. One of the the 
media types happends to be harddisc like so compact-flash and harddiscs (or 
files even) are fine too since all sector sizes >= 512 are ok.

Good thing to remember is that only CD-MRW and DVD+MRW media resemble a 
harddiscs somewhat on device model but others of the family are quite 
different.

Formatting media will be done in userland offcource with full SCSI access 
and a full format-type/format-time driven implementation could 
prolly/hopefully be made though things like the NWA just have to be queried 
for each write stretch.

The biggest challenge with UDF is IMHO the fact that switching from write 
to read can result in the loss of logical sectors due to link-blocks. If 
you write stuff on a CD-R at n, n+1, n+2 etc till sector m and have to sync 
and read a part, you not only loose capacity and significant time but you 
can only start writing again at m+7; sectors m+1 till m+6 just DONT exist 
and access to them will result in a relatively lengthy retry with 
failure... disc allocation thus is somewhat intertwined with the disc 
sheduling.

Somehow the disc sheduling has to be told to explicit go for read or for 
write requests. On switching from write to read the sync caches scsi/atapi 
call can be made automatically but the real disc sheduling has to be done 
in the filingsystem. Code like the `cdbounce' that just starts a fill-up 
read while it is writing a sector completely fails and is plain wrong for 
non rewritables.

The current cd code from scsipi can be used only if UDF can assure all 
writes to it are in whole sectors.  That brings be on a question i haven't 
found answered yet in the docs: can a filing system dictate the size of 
bufs it gets trough VOP_STRATEGY() ? (what to do with get/put pages i dunno 
yet; hopefully the generic ones).

A very blunt solution could be to create a file on a specified 
random-access filingsystem that tracks the changes. A `commit' phase will 
then write out all the sectors in the right order without needing to do 
read/write cycles but in the case of one `commit' phase for BD media such a 
file could end up a 50 Gb or more... and do we really want that? AFAIK the 
MacOS-X UDF client uses this mechanism.

Cheers,
Reinoud

--zhXaljGHf11kAtnf
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)

iQEVAwUBQxW91YKcNwBDyKpoAQLUMwgApVNHGv8Sa8SxEuUQ1FamJf4eAq7HHogC
FZ2BL5sMEWD938RD4VGCP9GMnI13fh3PJiqqPTyf6Di9zPtBSM0sH4gMFCUlpRWO
220R1wSQN2ATUPKTcy0RUJOJZu+dpIqfnBaVHJvkTPsMB2F9xtUYF1xtosAF2QYI
8/fFlgumWCLq9pvRmkE2H20uGBemEqivPsW8gRE50TBJfAS2rGSZuv2uSgFy8e/x
S2lNSH567NVu38H8ZoDZzOFheNbdl54ORpNvzPB4P1ZuL7u7zj27Oc5ddxGDP46L
3iS1LIWqXx+22NB2z8E8E1CrMFwGNWKIZT01+I3ftYEE49MOSFNMmw==
=pK3z
-----END PGP SIGNATURE-----

--zhXaljGHf11kAtnf--