Messages in this thread | | | Date | Mon, 25 Dec 2000 12:10:28 +0100 | From | Jens Axboe <> | Subject | Re: Driver for emulating a tape device on top of a cd writer... |
| |
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/
| |