Messages in this thread |  | | | From | Jens Benecke <> | | Subject | Re: tapefs | | Date | 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 Gefhrten nicht zhlen 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/
|  |