Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!hp-pcd!hpfcso!hpfcdc!brucet
From: brucet@hpfcdc.HP.COM (Bruce Thompson (greeley temp))
Newsgroups: comp.sys.hp
Subject: Re: Optical Library Management Schemes
Message-ID: <5570622@hpfcdc.HP.COM>
Date: 3 May 91 23:07:17 GMT
References: <1991Apr30.191403.6571@batcomputer.tn.cornell.edu>
Organization: HP Fort Collins, Co.
Lines: 58


	>We have 3 20gb HP servers which has added 192 partitions
	>to what I thought was an aready complex file system. Before
	>I try to reinvent the wheel what is out there for dealing
	>with these things and/or what have/would you do?
	>Using them as a glorified tape drive seems a waste.

Agreed!

	>The problems so far are:
	>What is on which disc when.
	>Who can mount the things - ( I tried a suid script to let users
					mount them - it doesn't work and
					I have no desire to make /etc/mount
					suid)


	>What to do when the system crashes? Some of the disks have to
	>be mounted rw to be useful but at 20+mins a pop to fsck
	>the buggers, even 5 sides mounted rw is a pain.

This will change in 8.0.  All the cartridges can be mounted rw.  If 
power is lost or the system crashes, only those cartridges that were 
in the drives at the time need to fscked.  Cartridges that were in the 
slots (i.e. not in drives) have their file systems marked clean.
Note this does not mean that cartridges in slots can not be accessed.
All file systems that have been "mounted" via mount(1m) still appear
available to users.

What this means to you is that all the cartridges can be mounted rw
at boot time at the desired mount points.  Users do not have to
mount a cartridge, access it, then unmount it.  You do not have
to make /etc/mount suid!

There are two exceptions to marking a mounted cartridge clean when
it is removed from a drive.  This first is if a named pipe is
created on the surface.  I guess you COULD put a named pipe on
a surface but it wouldn't seem too optimum. :-)
The second exception is when an unlinked-open file exists on the
file system.  This can cause file system blocks to be allocated
but not associated with a file if the system crashes.   

The June 1990 USENIX conference proceedings has a paper discussing
the design of the autochanger driver and its associated challenges
like fsck.  If you want I have an electronic copy (troff format) 
I could send you (or anyone else interested).  It's a little too big to post.
The title is "A Transparent Integration Approach for Rewritable
Optical Autochangers", page 119.


Bruce Thompson
Hewlett Packard
Greeley Storage Division
brucet@hpgrlf



"Assume standard disclaimer here"