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 <[EMAIL PROTECTED]>
* SuSE Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
