[comp.unix.questions] EPOCH-1 Experience requested.

krueger@tacvax.mdcbbs.com (02/08/90)

Does anyone out there have any experience (good or bad) with the EPOCH-1
product???  We have approximately 50gb of diskspace on SUN/ULTRIX/HP/APOLLO
workstations.  Will the EPOCH-1 work for me or is there another product 
that I should investigate?  We are examining 8mm subsystems at this time 
too.  I will post results if there is any interest.
-- 
+----------------------------+---------------------------------------------+
|  Ken Krueger               |    Voice: (714) 952-6151                    |
|  McDonnell Douglas M&E     |                                             |
|  Internal Systems Support  | Internet: krueger@tacvax.mdcbbs.com         |
|  5701 Katella Avenue       |     UUCP: uunet!tacvax.mdcbbs.com!krueger   |
|  Cypress, CA 90630-5099    |      PSI: PSI%31060099980024::KRUEGER       |
+----------------------------+---------------------------------------------+
|    Be nice to me, or I'll tell my uncle Freddy...    Sweet dreams...     |
+--------------------------------------------------------------------------+

urban@randvax.UUCP (Mike Urban) (02/10/90)

In article <608.25d144b3@tacvax.mdcbbs.com> krueger@tacvax.mdcbbs.com writes:
>Does anyone out there have any experience (good or bad) with the EPOCH-1
>product???  We have approximately 50gb of diskspace on SUN/ULTRIX/HP/APOLLO
>workstations.  

The Epoch-1 is a good product if you have a lot of disk space that you
expect to access only occasionally (system source code, for example).
In its spare time, it migrates files from the magnetic disk to WORM
(or, now, erasable optical) drives and doctors the inode so that the
data can be found when needed.  This gives a substantial reserve of
space on the magnetic disk that can be freed quickly when there is a
shortfall; if even more space is needed, magnetic files are `staged' to
WORM in real time.  All the software seems to work well; the system is
generally transparent (typically used as an NFS server), although
someone who does not know what is going on behind the scenes can make a
mess of things.

Our problems come in because we have just one WORM drive, when there is
a demand for data from more than one WORM cartridge; the system goes
into an inevitable swap-'til-you-drop dance in the WORM jukebox and the
poor processes trying to access those files wait for the dance to
complete.  We had one case where errant shell scripts on multiple NFS
clients attempted to uncompress a huge file from the WORM, and the poor
Epoch kept trying to write files out to another WORM cartridge to make
room for the result... if you anticipate accessing files from optical
disk frequently, you should consider getting additional optical
drives.

Epoch's service people are knowledgable and responsive.  We have
particular problems because our machine is in a classified area and the
Epoch folks cannot call it up remotely to diagnose problems; they have
performed bravely under these circumstances.  We have had more than our
share of problems with the SCSI drives, but Epoch claims that they were
apparently shipped some bad drives from Maxtor, and the problem has
since been solved; everything else has been pretty solid.

Epoch's backup software is particularly well designed.  Our operators
complain because it `takes care of too much stuff automatically', and
that makes them nervous.

There are some problems, generally along the theme of `I would rather
do it myself.'  There is no C compiler, so porting your favorite local
software is impossible.  The system keeps track of optical and magnetic
disk (and tape) volumes with an Ingres database, but none of the
details of that database nor any operation information is documented by
Epoch; you must rely on their front-end programs for all operations.
This is unfortunate when you want to do something a little out of the
ordinary (as, `I mislabeled that WORM volume; please forget all about
it').  On balance, however, we have been pleased with the product and
are considering getting another for our unclassified systems.

-- 

	Mike Urban
	urban@rand.ORG