From:	MERC::"uunet!ARISIA.dnet.ge.com!CRDGW2::CRDGW2::MRGATE::SMTP::CRVAX.SRI.COM::RELAY-INFO-VAX" 13-APR-1992 14:47:16.92
To:	galaxy::GleEve
CC:	
Subj:	Re: TGV MultiNet vs. WIN/TCP NFS Client

From:	RELAY-INFO-VAX@CRVAX.SRI.COM@SMTP@CRDGW2
To:	Everhart@Arisia@MRGATE

Received:  by crdgw1.ge.com (5.57/GE 1.137)
	 id AA19774; Mon, 13 Apr 92 01:36:44 EDT
Received: From TGV.COM by CRVAX.SRI.COM with TCP; Sun, 12 APR 92 11:32:54 PDT
Date: Sat, 11 Apr 1992 10:41:48 -0700 (PDT)
From: KASHTAN@TGV.COM (David L. Kashtan)
Subject: Re: TGV MultiNet vs. WIN/TCP NFS Client
To: TIHOR@ACFcluster.NYU.EDU
Cc: KASHTAN@TGV.COM, info-vax@sri.com, info-multinet@TGV.COM,
        wintcp-l%ubvm.BITNET@TGV.COM
Message-Id: <703014108.884000.KASHTAN@TGV.COM>
In-Reply-To:  <01GIPZP9EN3UAXFLQA@ACFcluster.NYU.EDU>
Mail-System-Version: <VAX-MM(309)+TOPSLIB(155)@TGV.COM>
Postal-Address: TGV Inc.; 603 Mission St.; Santa Cruz, CA 95060
Phone: (408) 427-4366 or (800) TGV-3440

> 
> Let me just mention one other approach.  Pathworks for VMS (mac) uses  meta
> files but stores roughly one per directory with the shared information (and a
> separate subdirectory with other resource data in it.)   Nontheless if  the
> problem is using up FILE HEADERS then the best fix would bea  meta data file
> with all the file information in it for whatever granularity  you want. Of
> course that makes the "moving the file and losing the attributes" problem WORSE
> but if thats the key issue then do it.
> 

This is a good approach for a server but has some problems when used in
a client.  The Pathworks server has sole control over these files (it is
the ONLY server manipulating these files) but there may be multiple NFS
clients manipulating these meta-files.  There would need to be mechanisms
for locking parts of this per-directory database as multiple VMS clients
work in the same directory.  The current 1 meta-file per data file (worst
case) completely avoids this problem -- also one of the reasons why a change in
the meta-file requires us to rewrite the entire contents in a single NFS
write operation.  The worst case with the current situation is exactly the
same as 2 applications simultaneously modifying the attributes of a single
file, one wins and the other loses.  With your proposal the potential for
corruption of attributes of OTHER files exists when more than one VMS client
is operating in the same NFS directory.

I think this issue of using up FILE HEADERS is a red herring.  In almost all
circumstances you run out of file space long before you would run out of
FILE HEADERS.  The absolute worst case is when you store nothing but VMS
files and every file requires a meta-file -- in this case double the number
of FILE HEADERS (inodes) would be used than with the TWG scheme.  To avoid
this you would be giving up a fair amount of functionality as well as data
sharing ability.  In the real world this just doesn't happen.

David