lkml.org 
[lkml]   [2000]   [Dec]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: 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/

    \
     
     \ /
      Last update: 2005-03-22 12:52    [W:7.306 / U:0.264 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site