dan@rna.UUCP (Dan Ts'o) (06/28/89)
I just heard about a new device called the OCU-100 (Optical Conversion Unit) from TenX Technology in Austin. It is a SCSI device that sits between the host/SCSI bus and a WORM drive and makes the WORM emulate a read/write disk. It seems pretty well thought out and apparently works with any SCSI host and OS, including MVAX's, Sun's and PC's running UNIX. Its success is of course application dependent, but given a good match (lots of static data, a few changes), you can pretend that it is a read/write disk and need no special device drivers. You can pretend that the entire optical capacity is available as read/write because it does data compression and the extra capacity generated usually covers the extra sectors required for the small changes (in an archival application). A cute feature is that you can backtrack in time and examine the (UNIX) filesystem state at any time in the past. It also looks like a 512byte sector device, even if the WORM is a 1K or 2K device. So it sounded good to me. Does anyone have any experience or further knowledge or opinions about it ? Cheers, Dan Ts'o 212-570-7671 Dept. Neurobiology dan@rna.rockefeller.edu Rockefeller Univ. ...cmcl2!rna!dan 1230 York Ave. rna!dan@nyu.edu NY, NY 10021 tso@rockefeller.arpa tso@rockvax.bitnet
uri@arnor.UUCP (Uri Blumenthal) (06/29/89)
From article <680@rna.UUCP>, by dan@rna.UUCP (Dan Ts'o): > > ...... > ......makes the WORM emulate a read/write ...... Well, maybe I'm not that smart, but how the hell can you emulate read/write device on Write-Once-Read-Many? As I understand, it will be either TERRIBLY non-effective (like zillions of bytes be eaten as garbage), or it will not work at all (:-)! So to use it as a source archive (with modifications once in every 100 years), you probably can (if you're leaving at least 35% of WORM space free for those games). But that's all! Uri.
dan@rna.UUCP (Dan Ts'o) (07/01/89)
In article <191@arnor.UUCP> uri@arnor.UUCP (Uri Blumenthal) writes: >From article <680@rna.UUCP>, by dan@rna.UUCP (Dan Ts'o): >> ......makes the WORM emulate a read/write > Well, maybe I'm not that smart, but how the hell can you emulate read/write > device on Write-Once-Read-Many? As I understand, it will be either TERRIBLY > non-effective (like zillions of bytes be eaten as garbage), or it will not > work at all (:-)! > So to use it as a source archive (with modifications once in every 100 years), > you probably can (if you're leaving at least 35% of WORM space free for those > games). But that's all! Well, of course it wouldn't be very good for putting your /usr/spool/news filesystem on. But /usr/src, probably pretty good. The point is that many of us have storage applications requiring random, moderately fast access (scratch Exabyte), large capacity and not too many changes (images, for example, or school records), but have not been able to use WORMS effectively because existing OS's and device drivers and filesystems require read-write semantics. Special software drivers must be written to allow transparent access to WORMS from UNIX, MSDOS, VMS, etc. However this OCU box eliminates the need for special software by putting all those functions and workarounds in "hardware" (host and OS independent hardware). But the write-once limitation isn't going to go away, not entirely. Sometimes you want 800Mb of archival info on a $100 cartridge.
terryl@tekcrl.LABS.TEK.COM (07/05/89)
In article <423@siswat.UUCP+ buck@siswat.UUCP (A. Lester Buck) writes: +> In article <191@arnor.UUCP> uri@arnor.UUCP (Uri Blumenthal) writes: +> >From article <680@rna.UUCP>, by dan@rna.UUCP (Dan Ts'o): +> >> ......makes the WORM emulate a read/write +> > Well, maybe I'm not that smart, but how the hell can you emulate read/write +> > device on Write-Once-Read-Many? As I understand, it will be either TERRIBLY +> > non-effective (like zillions of bytes be eaten as garbage), or it will not +> > work at all (:-)! +> > So to use it as a source archive (with modifications once in every 100 years), +> > you probably can (if you're leaving at least 35% of WORM space free for those +> > games). But that's all! +> +> Well, of course it wouldn't be very good for putting your +> /usr/spool/news filesystem on. But /usr/src, probably pretty good. The point +> is that many of us have storage applications requiring random, moderately fast +> access (scratch Exabyte), large capacity and not too many changes (images, +> for example, or school records), but have not been able to use WORMS +> effectively because existing OS's and device drivers and filesystems require +> read-write semantics. Special software drivers must be written to allow +> transparent access to WORMS from UNIX, MSDOS, VMS, etc. However this OCU +> box eliminates the need for special software by putting all those functions +> and workarounds in "hardware" (host and OS independent hardware). +> But the write-once limitation isn't going to go away, not entirely. +> Sometimes you want 800Mb of archival info on a $100 cartridge. + +If you really want to know how to make a WORM look like a magnetic disk, +get a copy of the Summer '88 Usenix paper, "A UNIX File System for a +Write-Once Optical Disk", by Terry Laskodi et al. at Tektronix. +This is a filesystem built inside a Unix device driver which presents +a read/write disk to the operating system (though, of course, with lots +of writing the free space declines). Thanx for the plug, Mr. Buck, but I think I'd better clear up a few misconceptions you seem to have. First, you are correct that we provide the illusion to the OS that a Write-Once device is a Read-Write device, but we really did not build a file system inside the device driver. By the time a disk request is passed to a device driver, the only information the driver has is logical block number, a transfer count and transfer direction. What we really do in the device driver is to map the logical block number onto the real physical block number where the block actually resides on the medium. Of course, to do this we do need to maintain some data structures on the physical medium. All that information is encapsulated inside the device driver, but none of the higher level file systems operations know anything about this. For more excruciating detail, read the paper. Although the paper is(was) titled "A UNIX File System for a Write-Once Optical Disk", the methods we used are general enough to abstract onto almost any file system one might encounter (but we couldn't call it "A VMS File System for a Write-Once Optical Disk", we'd get laughed out of the conference!!!! (-:). +It is based on the report +"An Efficient I/O Interface for Optical Disks" by Jeffrey Scott Vitter, +Tech Report No. CS-84-15, June 1984, CS Dept, Brown University, where +Vitter presents some data structures for using WORMs and proves that +these algorithms are optimal (under some assumptions). Well, this is a judgement call, but our work wasn't based on Mr. Vitter's report alone. His was just one of a few papers on using Write-Once devices we surveyed in order to compare our work with. <WARNING: ENTERING GRATUITOUS BACK SLAPPING MODE> We like to think our work was more in keeping with the original UNIX philosophy, KISS (Keep It Simple, Stupid). Again, read the paper to find out why.... <ENDING GRATUITOUS BACK SLAPPING MODE> If you can't find a copy of the proceedings, drop me a line and I'll see if I can snail-mail you a copy of the paper. Terry Laskodi of Tektronix
buck@siswat.UUCP (A. Lester Buck) (08/08/89)
> In article <191@arnor.UUCP> uri@arnor.UUCP (Uri Blumenthal) writes: > >From article <680@rna.UUCP>, by dan@rna.UUCP (Dan Ts'o): > >> ......makes the WORM emulate a read/write > > Well, maybe I'm not that smart, but how the hell can you emulate read/write > > device on Write-Once-Read-Many? As I understand, it will be either TERRIBLY > > non-effective (like zillions of bytes be eaten as garbage), or it will not > > work at all (:-)! > > So to use it as a source archive (with modifications once in every 100 years), > > you probably can (if you're leaving at least 35% of WORM space free for those > > games). But that's all! > > Well, of course it wouldn't be very good for putting your > /usr/spool/news filesystem on. But /usr/src, probably pretty good. The point > is that many of us have storage applications requiring random, moderately fast > access (scratch Exabyte), large capacity and not too many changes (images, > for example, or school records), but have not been able to use WORMS > effectively because existing OS's and device drivers and filesystems require > read-write semantics. Special software drivers must be written to allow > transparent access to WORMS from UNIX, MSDOS, VMS, etc. However this OCU > box eliminates the need for special software by putting all those functions > and workarounds in "hardware" (host and OS independent hardware). > But the write-once limitation isn't going to go away, not entirely. > Sometimes you want 800Mb of archival info on a $100 cartridge. If you really want to know how to make a WORM look like a magnetic disk, get a copy of the Summer '88 Usenix paper, "A UNIX File System for a Write-Once Optical Disk", by Terry Laskodi et al. at Tektronix. This is a filesystem built inside a Unix device driver which presents a read/write disk to the operating system (though, of course, with lots of writing the free space declines). It is based on the report "An Efficient I/O Interface for Optical Disks" by Jeffrey Scott Vitter, Tech Report No. CS-84-15, June 1984, CS Dept, Brown University, where Vitter presents some data structures for using WORMs and proves that these algorithms are optimal (under some assumptions). I am not familiar with this OCU box, but there are many vendors offering optical storage solutions. They aren't really popular yet because every vendor considers their filesystem proprietary, so you depend on your vendor to support a given list of machines, ad infinitum. I am a member of the ANSI committe X3B11.1 which formed last week to do a volume and file structure standard for WORM media. If things go well, there should be a non-proprietary optical filesystem that all the major OS suppliers will support within 1.5-2 years. Then the market might really explode, because you can switch software vendors at the drop of a hat, and know your investment in disks will be good for decades. Of course, the many hardware standards for WORM are in a very sorry state, so you will still be tied to a physical media format for the forseeable future. -- A. Lester Buck ...!texbell!moray!siswat!buck
terryl@tekcrl.LABS.TEK.COM (08/26/89)
In article <423@siswat.UUCP> buck@siswat.UUCP (A. Lester Buck) writes: +> In article <191@arnor.UUCP> uri@arnor.UUCP (Uri Blumenthal) writes: +> >From article <680@rna.UUCP>, by dan@rna.UUCP (Dan Ts'o): +> >> ......makes the WORM emulate a read/write +> Well, of course it wouldn't be very good for putting your +> /usr/spool/news filesystem on. But /usr/src, probably pretty good. The point +> is that many of us have storage applications requiring random, moderately fast +> access (scratch Exabyte), large capacity and not too many changes (images, +> for example, or school records), but have not been able to use WORMS +> effectively because existing OS's and device drivers and filesystems require +> read-write semantics. Special software drivers must be written to allow +> transparent access to WORMS from UNIX, MSDOS, VMS, etc. However this OCU +> box eliminates the need for special software by putting all those functions +> and workarounds in "hardware" (host and OS independent hardware). +> But the write-once limitation isn't going to go away, not entirely. +> Sometimes you want 800Mb of archival info on a $100 cartridge. + +If you really want to know how to make a WORM look like a magnetic disk, +get a copy of the Summer '88 Usenix paper, "A UNIX File System for a +Write-Once Optical Disk", by Terry Laskodi et al. at Tektronix. +This is a filesystem built inside a Unix device driver which presents +a read/write disk to the operating system (though, of course, with lots +of writing the free space declines). It is based on the report +"An Efficient I/O Interface for Optical Disks" by Jeffrey Scott Vitter, +Tech Report No. CS-84-15, June 1984, CS Dept, Brown University, where +Vitter presents some data structures for using WORMs and proves that +these algorithms are optimal (under some assumptions). <Enter gratuitous back slapping mode, for the second time in as many months..> If you can't find a copy of my paper that Mr. Buck refers to, send me a SNAIL-MAIL address (NO EMAILS!!! The paper is NOT in a form that is suitable for email delivery), and I'll send you a copy of the paper. NOTE: the software described is NOT available for distribution, although it shouldn't be too difficult to reproduce.... Terry Laskodi of Tektronix terryl@tekcrl.labs.tek.com (If your mailer groks domains) OR (CHOOSE ONE) decvax!\ \ uw-beaver!tektronix!tekcrl.labs!terryl / ucbvax!/