Re: tapefs

Jens Benecke (jens@mail.conetix.de)
Fri, 18 Sep 1998 23:45:53 +0200


Am Wed, 16 Sep 1998 schrieb Richard B. Johnson:

>A tape file-system by any name is just a program (read user-mode)
>that puts directories for all the files on the tape SOMEWHERE.
....
>The problem is that a tape is a sequential device. You can't extend
>a file, you can't delete a file (although you can pretend to by
>marking its directory entry deleted).
>The result is a write-once file-system with abysmal performance.

The only thing I can remark about this is that I used to have a programm
('TSR') under DOS that did exactly this - it allocated AFAIR 2MB of RAM for
buffers and I was able to play Command & Conquer 2 from Tape instead of CDROM,
which was much faster than my 2x CDROM those days.

So, it _is_ possible. Whether a Linux port would fail at some (missing) kernel
feature I cannot say.

Something which IMHO would be much more interesting would be a cdrfs, like Spica
CD Manager (Windows) or RSJ CD Writer (OS/2). You mount the CDR, it allocates a
buffer on hard disk (20MB default), you cp, mv, ls, rm on this mounted CDR, it
writes to the buffer and when the buffer is full, it burns a track on CDR. If
the buffer keeps filling (e.g. a cp -a job), it just keeps burning, if the
buffer empties, it closes the track and waits for it to fill up again. For file
system it allocates a 1MB track at the beginning of the CDR which is being
written at umount time.

--
ciao, Jens			http://www.pinguin.conetix.de

* Das Verhalten von Gates hatte mir bewiesen, dass ich auf ihn und seine Gefährten nicht zählen brauchte. -- Karl May, Winnetou, Band 3

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/