[comp.os.vms] Distributed File Services.

everettm@tekgen.TEK.COM (Everett Mitchell) (04/28/88)

Below are the responses I received from my query about Distributed
File Services (DFS). I thought they may be of interest. DFS is one
of four products bundled under Decnet System Services (DSS). The
others are Remote System Manager (RSM), Distributed Queueing Service
(DQS), Distributed Name Service (DNS). 

Everett Mitchell
VMS System Support   DS 50/454
Tektronix, Inc.
P.O. Box 500
Beaverton, OR  97077

UUCP:		{ihnp4 | decvax | ucbvax}!tektronix!tekgen!everettm
ARPA:		everettm%tekgen.TEK.COM@RELAY.CS.NET
CSnet:		everettm@tekgen.TEK.COM
MaBell:		(503) 627-6516
----------------------------------------------------------------------

Received: by tekgen.BV.TEK.COM (5.51/6.24)
Received: by tekgen.BV.TEK.COM (5.51/6.24)
Received: by tekgen.BV.TEK.COM (5.51/6.24)
Received: by tekgen.BV.TEK.COM (5.51/6.24)
Received: by tekgen.BV.TEK.COM (5.51/6.24)
	id AA02157; Fri, 8 Apr 88 18:40:39 PDT
Received: by tektronix.TEK.COM (5.51/6.24)
	id AA12672; Fri, 8 Apr 88 18:43:34 PDT
Received: from q7 by tessi.uucp (3.2/SMI-3.0DEV3)
	id AA11914; Fri, 8 Apr 88 18:36:02 PDT
Date: Fri, 8 Apr 88 18:36:02 PDT
From: joey@tessi (Joe Pruett)
Message-Id: <8804090136.AA11914@tessi.uucp>
To: everettm@tekgen.BV
Subject: Re: DFS.
Newsgroups: comp.os.vms
In-Reply-To: <2714@tekgen.TEK.COM>
Organization: TSSI, Beaverton, Oregon

I've looked at it, but haven't bought a copy yet.  The biggest
problem I've run across is the price of the DNS (dist name server)
program.  It's $600 for a vaxstation II, but $7200 for a vax 3600
(the new microvax line).  I'm not sure that the vaxstation is up
to it, but I can't justify the amount for the 3600.  For 2 nodes
(all we have) it is about the same a clustering.  It looks like
after 2 nodes, DFS is cheaper than LAVC.  About the only thing
I can see that DFS doesn't give is diskless (or remote) booting.

If you find out anything more interesting, I would be interested
in hearing about it.

	Hope this was useful, call me for more info if you want
	Joe Pruett
	...!tektronix!tessi!joey
	643-9281

	id AA12198; Mon, 11 Apr 88 17:28:29 PDT
Received: by tektronix.TEK.COM (5.51/6.24)
	id AA15282; Mon, 11 Apr 88 17:31:30 PDT
Received: from OBERON.USC.EDU by ucbvax.Berkeley.EDU (5.59/1.28)
	id AA04470; Mon, 11 Apr 88 14:45:33 PDT
Received: by oberon.USC.EDU (5.51/5.5) id AA00637; 
	Mon, 11 Apr 88 14:17:46 PST
Received: by acrux.usc.edu (3.2/SMI-3.0DEV3) id AA05076; 
                Mon, 11 Apr 88 14:17:11 PDT
Message-Id: <8804112117.AA05076@acrux.usc.edu>
Date: Mon 11 Apr 88 14:16:56-PDT
From: Christopher Ho <oberon.USC.EDU!CHRIS%Acrux.usc.edu@ucbvax>
Subject: Re: DFS.
To: everettm@tekgen.BV
In-Reply-To: <2714@tekgen.TEK.COM>

> 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 just received DFS last week, and are trying it out now.  It's
definitely not the same as clustering, and trying to force it to be
won't work very well.  On the other hand, some of it's features are
better than clustering...

In our situation, we really needed mixed clusters (ie_ mixed LAVC and CI
clusters) and so DFS will have to serve as a poor substitute until we
get v5.0.  Among the disadvantages:
	o RMS shared writes are not supported.  This means, among other
	  things, that SYSUAF.DAT and VMSMAIL.DAT cannot be shared; for
	  you this may be either an advantage or disadvantage.
	o Many DECnet proxies need to be set up.  This may be a concern
	  if you have many prived accounts.  On the other hand, this
	  becomes moot if you're also considering clustering.

As concerns file access itself, yes it seems to work fairly well.  We
haven't really had it long enough to encounter real bugs or performance
problems, but it looks fairly reasonable.

Chris Ho
-------
	id AA16634; Tue, 12 Apr 88 14:23:51 PDT
Received: from csnet-relay by tektronix.tektronix.TEK.COM id jt17567;
          12 Apr 88 14:01 PDT
Received: from relay.cs.net by RELAY.CS.NET id ad03354; 8 Apr 88 22:26 EDT
Received: from acf4.nyu.edu by RELAY.CS.NET id aa24114; 8 Apr 88 21:51 EDT
Received:  by acf4.NYU.EDU (5.54/25-eef)
	id AA11067; Fri, 8 Apr 88 21:49:49 EST
Date: Fri, 8 Apr 88 21:49:49 EST
From: Stephen Tihor <tihor@nyu-acf4.arpa>
Message-Id: <8804090249.AA11067@acf4.NYU.EDU>
To: everettm@tekgen.TEK.COM
Subject: Re: DFS.
Newsgroups: comp.os.vms
In-Reply-To: article <2714@tekgen.TEK.COM> of 7-Apr-88 17:53 EST

Its ok but not a full replacement to clustering.  IT does give you most
of the advantages w/r/t file sharing but does not reduce the administrative 
burden the way a homogenous cluster does.  Depends on your real goal in
it all.
	id AA25327; Tue, 12 Apr 88 22:12:46 PDT
Received: from csnet-relay by tektronix.tektronix.TEK.COM id as04962;
          12 Apr 88 22:08 PDT
Received: from relay.cs.net by RELAY.CS.NET id ul01202; 12 Apr 88 22:57 EDT
Received: from vaxc.stevens-tech.edu by RELAY.CS.NET id aa25364;
          12 Apr 88 17:58 EDT
Date: Tue, 12 Apr 88 16:54:34 EST
From: "David L. Stevens" <DSTEVENS@vaxc.stevens-tech.edu>
To: everettm%tekgen.tek.com@relay.cs.net
Subject: RE: question about DFS
X-Vms-To: Q%"everettm%tekgen.tek.com@relay.cs.net",DSTEVENS    
Message-Id: <88312165435.2160092a.DSTEVENS>


 Hi, we just put in an order for that utility.  One requirement we know of is
 that you need to buy a copy of DNS (distrib. Name Service) for your network.
 Note that this is 1 copy for the network.  From what we had heard it sounds
 like a nice system, by making the file transfer n-times faster than DECnet
 file transfer.  Could you send me copies of the responces you get on DFS.

 Thanks,
 Dave Stevens
 Senior Systems Programmer
 Stevens Institute of Technology

 Bitnet:	DSTEVENS@SITVXC
 Internet:	DSTEVENS@VAXC.STEVENS-TECH.EDU
------------


	id AA20594; Thu, 14 Apr 88 22:42:08 PDT
Received: by tektronix.TEK.COM (5.51/6.24)
	id AA02008; Thu, 14 Apr 88 22:45:13 PDT
From: NMFECC.ARPA!KARCHER%MIT.MFENET@ucbvax
Received: from NMFECC.ARPA by ucbvax.Berkeley.EDU (5.59/1.28)
	id AA28871; Wed, 13 Apr 88 21:14:17 PDT
Received: from mit.mfenet by ccc.mfenet with Tell via MfeNet ;
	Wed, 13 Apr 88 19:42:04 PDT
Date: 	  Wed, 13 Apr 88 19:42:04 PDT
Message-Id: <880413194204.21a0021e@NMFECC.ARPA>
Subject:   RE: DFS
To: tektronix!tekgen!everettm@ucbvax.Berkeley.EDU.ARPA
Comment: From KARCHER@MIT.MFENET on 13-APR-1988 22:44:19.02 EDT

In response to your INFO-VAX posting on DFS: 

We've used DFS for some time. It's helped make the wait for mixed LAVC/CI
clusters a bit more bearable but I wouldn't call it an alternative to
clustering. It's helped us better centrally manage a LAVC of Vaxstations and
provide a common environment for the LAVC users. We have made some users' home
directories be DFS disks so they can login to a node and see their files even
though those files are "served" by another node. However, DFS appears to be most
useful for serving directories that contain public files to other nodes
without using additional disk space since there is only a single copy of the
files. Things with huge disk space requirements such as TeX are now available on
smaller systems where the lack of disk space would otherwise prevent their use.
Serving such public directories in a network eliminates users having to login to
a certain node just to run public software that's not available elsewhere.
Updates to these directories then need to be done once, eliminating any problems
caused by running the wrong version. Using DFS as an extension to clusters
(rather than an alternative) seems to make the best use of it. We could live
without DFS but not without clusters. Right now I'd trade DFS for mixed cluster
support hands down. When (if) we ever get mixed clusters, the benefit we get
from DFS will be less but since we can't cluster everything it will still have
value in serving public directories as described earlier. 

Performance is far better than DECNET but not quite as good as LAVC. It's
definitely not as good as a local disk but depending on what your doing this
may not be noticeable. For editing files and running images on a DFS disk,
it has little impact. For reading/writing a lot of data, it will be slower.
The type of ethernet interface is a factor in this too with DEUNA's being
worst and DEQNA's much better. The figures we have measured for DFS performance
for DEQNA to DEQNA transfers on a file with 512 byte records are as follows:

        DFS is:
                138% faster than DECNET
                25% slower than LAVC disks
                41% slower than a local RD54

If you aren't aware of the current "shared write" restriction it might have a
large impact. This prevents DFS access to files that are open for SHARED WRITE
by any process ANYWHERE. Even one process with a file opened for write will
prevent others from reading it. Because of this, images can only be installed
from a DFS disk if they are installed /NOSHARE. Also, a batch log file cannot be
read while it's open for write by the job controller. 

If you think any of this would be useful to INFO-VAX, feel free to post it.

C. A. Karcher
Systems Manager
MIT Plasma Fusion Center

KARCHER%PFCVAX@MIT-XX.LCS.MIT.EDU.ARPA
KARCHER%MIT.MFENET@NMFECC.ARPA
KARCHER%MIT.MFENET@ANLVMS.BITNET