Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!pasteur!ucbvax!gvg10.UUCP!mac
From: mac@gvg10.UUCP
Newsgroups: comp.os.vms
Subject: DFS again.
Message-ID: <8805021341.AA03679@gvgpsa.gvg.tek.com>
Date: 2 May 88 13:41:39 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 64

I did not see my reply come back so I thought I would send it again.
Geeeez, it really is a drag that no one owns this discussion, knows
how it's supposed to work or responds to queries about how it does work.

> Has anyone had experience with Distributed File Services? We
> are looking at this as an alternative to clustering, and would
> appreciate any input we can get about it.... how well it works,
> whether it works at all, etc. Thanks.
        
We are a manufacturing company that uses Vax'en for our business systems.
To increase our capacity we have just purchased 12 Vax 2000 class machines.
We did this instead of increasing the capacity on our CI cluster mainly
at upper management's request to do ``distributed processing''.  The
MIS manager here was told at DEC world that DFS would allow us to access
our data bases from the 2000 class machines until V5 mixed clusters
were available.

Well, yes and no.  We can access the CI served disks from the 2000's,
but the only shared access DFS allows is exclusive reads.  When DFS
is reading a file no one, no where can have write access to the files.
Of course, what we had hoped was that we would be able to turn our 2000's
into inquiry engines.  But keeping the inventory folks from shipping
product so that someone in marketing can find out how many video switchers
were sold into Iran last year is not very popular.  So for our application
it does not really work.

Okay, so no shared access.  But I can snap short the data base and do my
big material resource planning (MRP) generation on private files
on the CI disks, right? Wrong.  When DFS opens files for write it changes
the rms access to exclusive, and of course our MRP program is efficient,
it attempts to have the primary file open on multiple channels at once.
Of coourse DFS will not allow the second open and the process fails.

So we find jobs that do not open the files twice and run those, right?
Wrong.  We found running heavy IO jobs accessing DFS disks on two stations
bring the DFS serving 8200 goes to its knees.  Everything looks fine for
the stations, but the 8200 is really grim.  Login time goes to 5 minutes,
the interrupt and kernel activity dominate the machine, interrupt stack
time is seen to peak above 85 percent.  What's going on? It's only like
two more processes right?  Well, the DFS server software is really an
ACP and it runs at a base priority of 8.

So why not dedicate the 8200 to service DFS.  Here is where we are bitten
by our CI cluster configuration.  We have an 8530 and an 8200 in cluster,
but the 8200 is the only machine with a unibus and we have some unibus
devices that we need to use.  Yuck, it's really hard to get this egg
off of our face after suggesting the purchase of the 2000's.  So the
only real solution for us at this point is V5 of VMS.

What this really says is ``Be careful out there''.  The Vaxstations
that we got are really wonderful for the developers and it is really
impressive to do a SHOW DEVICE D and see 20 RA81's out there.  But,
DFS is not there yet for shared file applications and heavy IO loads
will required a dedicated server.  Unfortunately, we found out the hard
way, but now that I have a station on my desk, they will have to shoot
me before I let them take it away.

Bill

----------------------------------------------------------------------
| Bill MacAllister          |    Email address:                      |
| The Grass Valley Group    |      Mac@GVG49.Email.Hub.Tek.Com       |
| PO Box 1114               |      Tektronix!GVGPSA!GVG49.uucp!Mac   |
| Grass Valley, Ca  95945   |                                        |
----------------------------------------------------------------------