Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!usc!ucsd!network.ucsd.edu!weber!corrigan
From: corrigan@weber.ucsd.edu (Michael J. Corrigan)
Newsgroups: comp.sys.hp
Subject: Re: 20Gb OPTICAL INFO
Message-ID: <2315@network.ucsd.edu>
Date: 29 Mar 90 01:41:26 GMT
References: <1990Mar14.183210.915@ux1.cso.uiuc.edu> <1080137@hpfcmgw.HP.COM> <7370110@hpfcso.HP.COM>
Sender: nobody@network.ucsd.edu
Reply-To: corrigan@weber.ucsd.edu (Michael J. Corrigan)
Organization: Division of Social Sciences, UCSD
Lines: 68

In article <1080137@hpfcmgw.HP.COM> rocky@hpfcmgw.HP.COM (Rocky Craig) writes:
   >> ...my understanding is that the jukebox
   >> looks like one massive 20GB device and the info on where each file is
   >> located is stored in the superblock.
   >
   >This is not correct.  You can individually mount(1M) each SURFACE of a 
   >single disk as a file system.  The 7.0 driver(s) take care of grabbing
   >the correct media, flipping it around, etc., so that access to the
   >many filesystems is transparent (if not immediate :-) to the user.

Right, not immediate. It would take over 10 minutes for a df to complete on a 
fully loaded and mounted jukebox ( the first time through and then this info 
is in the disk buffer cache) 
   >
   >Number of disks: 32 max \   so there are up to 64 filesystems available
   >Sides per disk:   2	/   in a "loaded" autochanger
   >
   >Bytes per side:  325 megabytes (the maximum size for a single filesystem)
   >

325 Mb is "unformatted" so to speak in that you get
265 Mb per side with a 10% minfree fs, and 295 Mb if you exceed the minfree.

   >20 Gigabytes is 32 * 2 * 325 megabytes.  I believe you can actually mount

16.6 Gb is 32 * 2 * 265
or
18.4 Gb is 32 * 2 * 295    but heck, what's a couple of gigabytes ?

   >all 64 filesystems (but what an fsck nightmare!!!!)

Actually, not that bad: 13.3 minutes for fsck preening 64 sides, assuming
they were umounted cleanly. 2.6 hours at worst assuming no nail-biting
questions posed ( Unknown File Type I=2 (Clear) ?).
   >
   >Rocky Craig			
   >Hewlett-Packard Workstation Group, Marketing Event Technical Support
   >Internet:	rocky%hpfcmr@hplabs.hp.com
  >This article does not represent the official position of the Hewlett-Packard 
  >Company.  The above data is provided for informational purposes only.  It is 
  >supplied without warranty of any kind.

and 
In article <7370110@hpfcso.HP.COM> dlj@hpfcso.HP.COM (Dave Jobusch) writes:
[deleted]
  >
  >My group is currently using two "jukeboxes" connected to a 370 for
  >a backup project.  The scheme that our programmer is using (and 
  >I believe what the manual suggests as well) is to mount only 2 surfaces 
  >(per jukebox) read/write, and mount the rest as read-only as needed. 

The manual doesn't say that. It says:

"You can have as many read/write surfaces as you want: however you should 
minimize the number of surfaces mounted read/write [because if] ... the
system's power fails, all write-mounted surfaces will require ... fsck.
The time required ... could be excessive" (HP pn C1700-90000,10/12/89,page 9-6)

2 surfaces (from different disks) is the number to mount to avoid disk swaps.
  >
  >Fsck'ing 20GB would take awhile :-)
  >
  >|          ___         |       David L. Jobusch
  >|         /  /         |       Distributed Systems Suppport
  >|  Fort Collins Site   |       Internet: dlj@hpfcla.hp.com

Michael J. Corrigan
corrigan@ucsd.edu