isodonovan@brb.isnet.inmos.co.uk (10/25/89)
-------------------------------------------------------
RV20 (DEC 'WORM' Optical Disk) Digest of known problems
-------------------------------------------------------
INITIAL POSTING
---------------
On 5th October I posted a note about certain features that we had
discovered with our RV20.
If when writing to the disk any of the following occur:
(1) Control/Y
(2) Control/C
(3) Vax Crash
(4) Drive failure
(5) Any other process-abort
The controller burns an 'end of disk' mark at its current position.
This gives you a choice from two options
(1) Re-initialise the disk to have access to the remaining free space
(and lose everything written so far)
(2) Retain the written information
(and lose the ability to write anything else)
I asked whether anyone else had had similar experience, and whether there
were any third party disk drivers which acted in a more graceful manner.
It would appear that the RV20 driver acts the way it does because it is
really a tape driver. On a tape, of course the 'end-of-tape' mark could be
overwritten.
RESPONSES
---------
(1) From Carl Karcher, who found that using a large block size would do
damage too:
--------------------------------------------------------------------------------
Date: Fri, 6 Oct 89 11:20 CDT
From: "Carl Karcher, Room 535 WC, 3-5896" <KARCHER@don.waisman.wisc.edu>
Subject: Re: RV20 woes
To: isodonovan@isnet.inmos.co.uk
X-Vms-To: IN%"isodonovan@isnet.inmos.co.uk"
We have found this out too. We don't even need a crash or job abortion to
cause the disk to be burned - it happens for us automaticaly if a large
block size is used. We tried using 32256 and had two "DATALOST" errors on a
platter. Field service suggested lowering the blocksize. We tried 3016 (a value
from the table 2-1 in the owners manual) and wrote another platter with no
errors. What block size to you use? From the description of the sector packing
in the owners manual is seems that unlike tapes, a large vs small block sizes
is not a big trade off for a continuous transfer. It appears more important to
pick the "right" block size to achive the best sector packing - .i.e. one of the
"optimal block sizes" in the table 2-1. What's your experience? It also seems
that all the even "Number of sectors" entries in the table are off by 2,
according to the descriptions of the sector packing.
The Q-bus KLESI controller for our RV20 is in front of a KDA50 disk controller
which is where Atlanta said to put it, but seems wrong from my experience. Do
you know where your KLESI is positioned the bus?
Any RV20 experience you can offer would be appreciated as it seems there
are not too many of us that own one.
Thanks.
Carl Karcher Internet: KARCHER@WAISMAN.WISC.EDU
Systems Manager Bitnet: KARCHER@WISCPSL
UW - Waisman Center Hepnet: KARCHER::PSLC
Madison, Wisconsin PSTNet: (608) 263-5896
--------------------------------------------------------------------------------
To which my reply was:
--------------------------------------------------------------------------------
From: DF::ISODONOVAN "Brian O'Donovan, Inmos Information Systems" 9-OCT-1989 14:22:24.23
To: BRWL::"karcher%don.waisman.wisc.edu@earn-relay.ac.uk"
CC: ISODONOVAN
Subj: RE: Re: RV20 woes
Hi Carl,
Thanks for your response.
I'm not a Technical Support person so I'm not that familiar with the hardware,
my apologies if my technical terminology is not perfect.
We are fortunate to have only had the one nasty experience. If one of the
Vaxes had not gone down, we'd probably still be none the wiser.
Apparently we use a block size of "around 5000". We don't use a Q-bus, our
RV20s (we have 2) hang off a UniBus, and (they tell me) the KLESI is a Q-bus
thing, so we don't have one.
Apart from the fragility re: Crashes, Spin-downs, CTRL/Cs, CTRL/Ys - and your
experience with block sizing, our system manager reckons there are no other
'nasties' connected with the RV20. The advice at the moment seems to be to
minimise the time spent writing to the disk. I suppose that would mean
creating a backup saveset on magnetic media and then just copying it to the
optical. The other advice would be to disable CTRL/Y and CTRL/C whilst
writing.
If any really useful information comes to light I will be sure to let you know.
Please keep me in touch with your experiences of the beast.
many thanks
brian
--------------------------------------------------------------------------------
(2) From an individual whose mail I have mislaid who was looking for
informantion on RV20s. I hope they get to see this, an that it is
useful.
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
LASTLY
I am still interested in hearing of third party drives or any other
workarounds for the problems. Please send mail and I will summarise.
I'm sure Carl would be interested in hearing from anyone with a similar
hardware setup to his.
I hope this hasn't been too long and boring for you.
-- Brian
o------------------------------------------------------------------------------o
| Brian O'Donovan, Inmos Information Systems |
o------------------------------------------------------------------------------o
| mail: Inmos Ltd, Cardiff Road, Dyffryn, Newport, Gwent, Wales, UK, NP9 1YJ |
| phone: (0633) 810121 extension 322 |
| email: ISODONOVAN@uk.co.inmos.isnet (or ISODONOVAN@isnet.inmos.co.uk)? |
o------------------------------------------------------------------------------o
| "Is there anybody out there?" |
o------------------------------------------------------------------------------o