Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!sundc!texsun!sun!plx!forster
From: forster@plx.UUCP (Jim Forster)
Newsgroups: comp.periphs,comp.unix.wizards
Subject: Re: Filesystem/archive formats for WORM optical disks
Message-ID: <713@plx.UUCP>
Date: Wed, 19-Aug-87 19:22:35 EDT
Article-I.D.: plx.713
Posted: Wed Aug 19 19:22:35 1987
Date-Received: Sat, 22-Aug-87 09:39:43 EDT
References: <615@orcisi.UUCP>
Organization: Plexus Computers, San Jose, CA.
Lines: 55
Xref: mnetor comp.periphs:539 comp.unix.wizards:3786

in article <615@orcisi.UUCP>, michael@orcisi.UUCP (Michael Herman) says:
> 
>> I guess I was under the impression (and still am) that WORM drives would
>> be good for doing things like:
>> 	dd if=/dev/rrf0g of=/dev/rworm99 bs=32k
>> And then mounting /dev/worm99 read-only...
> 
> Don't read-only Unix file systems still update last access times?

and,

in article <218@casemo.UUCP>, brian@casemo.UUCP (Brian Cuthie) writes:
>You're right! you can do this.  But, do you have 1 Gbyte in magnetic disk space
>to first create the filesystem you want to dd ??  

Plexus has support for 14" Optimem Optical drives, and in fact, we use them
just like you suggested.  We have a utility so that the optical disk
can be carved into named partitions and sized, etc., and then associated 
with a particular minor device.  We then copy a file system to that device,
using dd, and then mount that hunk read-only.  Works great.  
We have 1Gb optical drives on-line, each with various numbers of file systems
mounted. Its real handy to have enough storage to keep old sources and 
usenet archives online.  I didn't do any of the actual work on this 
project, but contributed a little to the design, so I thought I'd explain 
what we did.  

We also use them in some other ways: piping the output of cpio into the
program that creates an O.D. partition is a handy way to backup something.
Later you just cpio it out.  One other way we use Optical Disks is with a 
Data Base program that knows about the optical disk, and which does space 
management knowing that it will never be able to re-write anything.

The Optimem drives (and a Hitachi we looked at) don't have the
sector-postamble-redirect feature of the Optotech units, which sounds handy, 
so we developed a scheme that works pretty well.  With these drives, if you 
ask to read 10 sectors, but only 3 have been written, the controller will 
tell you this, and this turns out to be handy.  

We don't use a bitmap, but do have directory-like structures that would like 
to be updated.  To do so, we allocate 10 sectors, say, to store one sector, 
and initially write the information to the first sector.  To update this sector,
we re-write it into the next position in the block of sectors.  To read the 
information, we attempt to read 10, but only look at the last sector that was 
written, and thus get the most recent information.  This burns a sector each 
time it's updated, but at least the location of the information on the disk 
hasn't changed.  

There's a little issue of what to do when you fill up the 10 sector block, 
so you move the block, and then have to update the pointer to that block, 
so you use the same scheme on that block, realizing that you'll only have 
to update it 1/10 as often as the child block.  


	Jim Forster
	Plexus Computers