Hi Jeremy,
On Fri, Jun 04, 2004 at 04:43:30PM -0400, Jeremy Jackson wrote:
> Hi XFS,
>
> I've started working on a drive_optical.c strategy routine for xfsdump.
> So far I am amazed how well xfsdump was designed for different media
> paradigms. With flags for device capabilities "can overwrite" etc, it
> is looking easier than I thought.
>
> I was wondering if it would be appropriate to have the following added
> to CVS (maybe commented out for now) as a place holder.
>
> common/drive.h
> #define DRIVE_STRATEGY_OPTICAL 2
>
Fine by me.
I don't think there is a rush on strategy numbers though :-)
Could wait for the future patch :)
> Any advice or help from XFS developers or anyone else will be appreciated.
>
> It seems that the Linux kernel now has very much of the required device
> driver support. CDs have the concept of tracks, and DVDs have the
> concept of RZONEs, which map nicely to tape files.
>
> It seems that at least mmc3 devices are fairly uniform and simple.
>
> By removing 2 lines of code (that deny opening the block device
> read-write) , I am able to write CD-Rs in track at once mode using
> nothing more than dd (patched for O_DIRECT). Of course proper media
> detection (CD-ROM vs CD-R vs DVD+-R(W) etc) needs to be added.
>
> In my first pass, the dh_match function will use ioctl(fd,
ds_match
> CDROM_SET_OPTIONS, 0) to detect optical drives. This option is
> available on *all* devices based on the unified cdrom layer, and is a
> no-op. Some of the other CD specific ioctls vary/fail based on
> individual drive features detected at runtime.
>
> My strategy will be to add a few ioctl calls to the generic cdrom layer,
> and emulate these in an enhanced rmt (using packet commands) until the
> mainline kernel supports these functions. This will give the cleanest
> implementation in xfsdump, and will also allow others (dumpe2fs) to
> share the low level code.
>
> Basically the extra IOCTLs that are needed are to access to the
> following scsi/mmd3 commands:
>
> READ DISC INFORMATION/READ TRACK INFORMATION - this is already in
> mainline kernels, used internally by a few IOCTLs in the generic cdrom
> layer, but not exposed to userspace. This enumerates "tracks" (or
> RZONEs on DVD), which is required to simulate tape files and file marks,
> gives the address at which data can be appended (simulates tape EOD),
> and gives the absolute recordable size (to simulate tape EOM)
>
> the CDROM_SELECT_SPEED ioctl needs to also set the write speed.
> currently it always sets it to 0.
>
I know nothing about the CD/DVD driver support but
it sounds a good idea :)
--Tim
|