Subject: Re: scsipi woes: can't call scsi command from kernel by ioctl?
To: Bill Studenmund <firstname.lastname@example.org>
From: Reinoud Zandijk <email@example.com>
Date: 08/31/2005 16:25:32
Content-Type: text/plain; charset=us-ascii
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
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
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
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.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)
-----END PGP SIGNATURE-----