Minutes from Santa Fe DFS-WG meeting

Peter Honeyman <honey@citi.umich.edu> Thu, 05 December 1991 05:08 UTC

Received: from citi.umich.edu by NRI.NRI.Reston.VA.US id aa05550; 5 Dec 91 0:08 EST
From: Peter Honeyman <honey@citi.umich.edu>
To: dfs-wg@citi.umich.edu
Cc: mdavies@NRI.Reston.VA.US
Date: Thu, 05 Dec 1991 00:06:06 -0500
Subject: Minutes from Santa Fe DFS-WG meeting
Message-ID: <9112050008.aa05550@NRI.NRI.Reston.VA.US>

Internet Engineering Task Force
Distributed File Systems Working Group
DFS-WG

dfs-wg@citi.umich.edu is a mailing list for ongoing discussions of the WG.
Administrative matters, such as requests to be added or dropped from the
list, should be addressed to dfs-wg-request@citi.umich.edu, not to the list
as a whole.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

MEETING NOTES

The DFS WG met for the third time on 19 November 1991 at the Santa Fe
IETF.  The meeting attendance is shown at the end.


AGENDA

NFS developments
AFS-3 documents
AFS-3 congestion control
Announcements


NFS DEVELOPMENTS

Tom Kessler (tom.kessler@eng.sun.com) described work at Sun to add
local disk caching to NFS.

The Cache File System (CFS) is a generic mechanism that caches files
and directories from other VFS systems.  The principal cache repository
is UFS, i.e., the Berkeley FFS.

A principal design goal to boost NFS server performance by reducing
load, but CFS helps reduce network load as well if the cache hit rate
is high.  CFS is also useful for improving CD-ROM performance.

Like AFS-3, CFS caches chunks of files.  Unlike AFS-3, there is a
one-to-one correspondence between cached files and files on the
server.  Missing chunks are represented by "holes" in the cached file.

Consistency checking has not been implemented; CFS is a client-only
modification, so the consistency checking can be no stronger than that
in the VFS system being cached.  The consistency check mechanism is
modular and offers hooks for a CFS developer to provide alternate
enforcement mechanisms.

"Blot-out" mode lets you overlay files with local copies.  The unit of
blot-out is a complete file.  The local overlay is not purged from the
cache by ordinary LRU replacement policy.  Other files can be marked to
make them "sticky" in the cache.

CFS supports numerous write modes:

o       Write-through.  Synchronous with server.

o       Blot-out.  Write to cache only, make local copy sticky.  Useful
	for writing CD-ROM.

o       Write-around.  Modify actual file only.  Useful if cache is
	scarce resource.  [I may not have this right.]

Write-through is the normal mode.  CFS helps READ, READDIR, READLINK,
LOOKUP performance, does not help GETATTR, directory modifications,
WRITE, SETATTR.

As for the bottom line, Tom, who uses CFS on his home computer, was
asked "how does it feel?" According to Tom, "It feels pretty good."

Chris Silveri's foils, which Tom used in his CFS presentation, can be
obtained in PostScript form via anonymous FTP from citi.umich.edu.  See
/afs/umich.edu/user/h/o/honey/IETF/cfs-vg.ps.

OTHER NFS DEVELOPMENTS

There has been some progress on the part of vendors in tuning the NFS
parameters (tsize, RTO, RTT measurements) in systems they ship to
better conserve network resources.  A number of people reported that
they find NFS/UDP over the Internet satisfactory.  [At least one person
was surprised to hear this.]

NFS/TCP is commercially available, and is under development by many
vendors.  Connection maintenance is not entirely a solved problem.

Sun/RPC over TCP has problems with accurate RTT because the network
latency is smeared by the upper-layer (i.e., NFS) service times.  (See
"Transport Issues in the Network File System" by Bill Nowicki, Computer
Communication Review 19(2), pp. 16-20 (April, 1989) for related work.)

Watch Connectathon for further activity in the NFS/TCP arena.

AFS-3 DOCUMENTS

There was some discussion of the four-or-so inches of AFS-3 documents
made available by Transarc.  It is not clear what advantage there is in
putting an RPC imprimatur on them.  Nor is Transarc enthusiastic about
reformatting the documents to conform to RFC 1111.

AFS-3 CONGESTION CONTROL

Peter Honeyman (honey@citi.umich.edu) described his recent work on
congestion control for Rx.  (Joint work with Dave Bachmann and Larry
Huston.)  The goal has been to make AFS usable over slow links, down to
about 10 Kbits/sec.  Much has been accomplished so far, work
continues.

ANNOUNCEMENTS

There is a forthcoming Workshop on File Systems, to be held in Ann
Arbor on May 21-22, 1992.  Contact fsworkshop@citi.umich.edu for
further information.

ATTENDANCE

Mary Artibee            artibee@sgi.com
David Borman            dab@cray.com
Phil Budne              phil@shiva.com
Randy Butler            rbutler@ncsa.uiuc.edu
Lida Carrier            lida@apple.com
Yee-Hsiang Chang        yhc@concert.net
Richard Cherry          rcherry@wc.novell.com
Jim DeMarco             jdemarco@ftp.com
Peter DiCamillo         cmsmaint@brownvm.brown.edu
Joseph Godsil           jgodsil@ncsa.uiuc.edu
Olafur Gudmunddson      ogud@cs.umd.edu
Peter Honeyman          honey@citi.umich.edu
Holly Knight            holly@apple.com
Vincent Lau             lau@eng.sun.com
Tony Mason              mason+@transarc.com
Bill Melohn             melohn@auspex.com
Paul G. Milazzo         milazzo@bbn.com
Greg Minshall           minshall@wc.novell.com
RL "Bob" Morgan         morgan@jessica.stanford.edu
Brad Parker             brad@cayman.com
Eric Smith              eric@telebit.com
Mike Spengler           mks@msc.edu
Sven Tafvelin           tafvelin@cs.chalmers.se
Kathy Wilde             wilde@decvax.dec.com
Preston Wilson          preston@i88.isc.com
Nancy Yeager            nyeager@ncsa.uiuc.edu