mac@gvg10.UUCP (05/02/88)
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 | | ----------------------------------------------------------------------
everettm@tekgen.TEK.COM (Everett Mitchell) (05/10/88)
In article <8805021341.AA03679@gvgpsa.gvg.tek.com>, mac@gvg10.UUCP writes: > 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. > I made the inquiry about DFS over a month ago. I received about six mail responses, all of which I have replied to via mail (several mail msgs were returned - unable to make the connection; wrong path, maybe?). Anyway, I didn't post to the net because there did not seem to be the interest. However, I will do so now. Below are all the responses I received regarding my query about DFS. Thanks for your help. 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