[Top] [All Lists]

xfsdump optical drive strategy

To: linux-xfs@xxxxxxxxxxx
Subject: xfsdump optical drive strategy
From: Jeremy Jackson <jerj@xxxxxxxxxxxx>
Date: Fri, 04 Jun 2004 16:43:30 -0400
Sender: linux-xfs-bounce@xxxxxxxxxxx
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040122 Debian/1.6-1

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.


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



Jeremy Jackson
Coplanar Networks

<Prev in Thread] Current Thread [Next in Thread>