Subject: Re: scsipi woes: can't call scsi command from kernel by ioctl?
To: Bill Studenmund <email@example.com>
From: Manuel Bouyer <firstname.lastname@example.org>
Date: 08/31/2005 23:02:54
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
> 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
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 <email@example.com>
NetBSD: 26 ans d'experience feront toujours la difference