Re: Driver for emulating a tape device on top of a cd writer...

[Jens Axboe <axboe@suse.de>]

On Tue, Dec 19 2000, Stelian Pop wrote:
> > > Basically, I would like to be able to use a cdwriter as a tape
> > > device, with software like dump(8) or tar(1). With /dev/tcdw
> > > as name (for example), I'd like to be able to do:
> > > [...]
> 
> > What you describe is actually one of the goals of the packet writing
> > driver. To do this reliably you need packet writing, I won't even
> > start to think about the headaches wihtout it...
> 
> Yes, I saw your patch for packet writing but:
> - the CD written with packet writing software may not be readable
>   on standard CD-ROM drives (and I want that, because almost 
>   everybody has one).

On CD drives sold during the last two years or so, and of course
all DVD drives they are readable. But of course of you want 100%
coverage, it isn't good enough.

> - using packet writing you basically write _files_ on top of an
>   UDF filesystem. Tar and dump (or afio, cpio etc) does not
>   support that kind of access, they expect to be given a character
>   device they can stream data to. (Of course, it is possible to
>   add some additionnal level of indirection on top of the packet
>   device and provide character based access to the UDF files, but
>   IMHO _this_ would be overkill).

Why would you even want to use UDF for this? You want raw access
to the device. Packet writing or not, this is totally unrelated.

> - data backups are expected to be fast. Writing data in DAO/TAO
>   mode is much quicker than in packet mode.

No no no, not much quicker. Write large packets and it's just
as fast as dao/tao. 64Kb packets are a bit slower because of
run-in, run-out block over head, but using larger packets this
isn't the noticable. And packet writing has so many other
advantages...

> - reliability is a question of implementation. cdrecord can
>   be very reliable. If a user space application can provide this
>   level of reliability, it should be even simpler to achieve it
>   in kernel space (and I plan to use the BurnProof/etc extensions
>   which will be present on all future cdwriters).

Even simpler to achieve reliability in the kernel? I gather you
mean feeding-data reliability, and not stability.

> > > I'll start to work on this, probably by looking at the cdrecord 
> > > low level code and porting it into kernel space.
> > 
> > Oh god no! You can do all this from user space.
> 
> Please pay attention to the fact that I was refering to the 'low level
> code'. I don't intend to write a driver who can replace cdrecord. 
> _This_ would be madness.

Very much so

> What I indend to do is just a 'small' driver, which supports only the
> mmc drives. I expect the driver to be only some hundreds lines long.

A few hundred lines? *This* I look forward to seeing :)

> Doing that from user space would mean propagating the data from
> the user space application (dump or tar) to a character mode
> driver, and back to a user space application (something like a hacked 
> cdrecord), which will return in kernel space using sg interface...
> It could be easier to write (even if I don't exactly feel confident
> about hacking the cdrecord source :) ), but the reliability and
> the performance would be far far away...

Pipes and 100% user space based, then pass to sg? I don't see the
problem.

-- 
* Jens Axboe <axboe@suse.de>
* SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/