On Wed, Aug 31, 2005 at 04:25:32PM +0200, Reinoud Zandijk wrote:
> > > 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. 

dd can be usefull for some kind of backups, but doing direct writes with
dump or tar would be usefull too.

> 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 ?

Well, if we issue a write to the device, the driver will issue a
SCSI_WRITE_6_COMMAND or WRITE_10 to the device, which recent DVD-burners seems
to handle fine. As far as I can see nothing else special happens.
There is a PREVENT_ALLOW issued when the device is closed, which may be
what cause the disk to be finalised.

> 
> > 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.

Well, this isn't a problem if we do one big sequential write :)

> 
> 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.

I would expect some kind of cache to be needed for such a filesystem.
But is caching of the whole data set required ?

BTW, we're quite away from the IOCTLs issues here :)

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--