[15] in Open-Software-Foundation-News
meeting notes: DCE SIG, File System Working Group session
daemon@ATHENA.MIT.EDU (dstokes@austin.ibm.com)
Fri Mar 25 16:48:12 1994
Resent-From: Bill Cattey <wdc@MIT.EDU>
Resent-To: osf-news-mtg@menelaus.local
Date: Thu, 24 Mar 1994 12:42:56 -0600
From: dstokes@austin.ibm.com
To: info-afs@transarc.com
Thought this group might find this info interesting.
Thanks, Dawn
To: sig-dce-fs@osf.org
Subject: meeting notes: DCE SIG, File System Working Group session, 21-mar-94
Date: Thu, 24 Mar 94 12:07:02 +28616
From: "Andy Kegel, DCE/DFS for DEC OSF/1" <kegel@zk3.dec.com>
X-Mts: smtp
Joint DCE & Management (DME) SIG meeting
File System Working Group session
21 March 94, Santa Cruz, CA
Meeting notes by Andy Kegel@zk3.dec.com
Agenda
+ Select new Chair
+ DFS V1.1 Overview
+ DFS support of "slow" devices - discussion
+ DFS support of "mass storage" devices - presentation and discussion
+ DFS performance metrics - discussion
+ Wrap-up
New Chair selected by acclamation:
- Mark Sherman, Transarc
- mss@transarc.com
- (412)338-4420
Attendees (please excuse any typos in the names):
Andy Kegel, Digital Joseph Boykin, GTE Labs
Sarr Blumson, U-Mich Rich Bennett, AT&T-GIS
Mark Sherman, Transarc David Klitzke, UNISYS
Raman Khanna, Stanford Robert Duncan, Northern Telecomm
Jonathon Goldick, Pittsburgh Supercomputing Center
Bill Zumach, Pittsburgh Supercomputing Center
Jim Mostek, Cray Research
Liza Martin, HP John Diehl, Caltech/JPL
David Wright, Hitachi Hilary Jones, Sandia National Labs
Bob Printis, Xerox Terry Burch, Boeing
Steve Dahlby, IBM Jim Showalter, IBM
Jerry Dolan, EDS Mike Browder, SCO
Dan Wu, DOD/DISA Y. Sastry, HAIS
Mike Lanni, EDS Art Gaylord, U-Mass/Proj Pilgrim
Bob Holtgraver, Alcoa Madju Vadde, UNISYS
Marcie Desmond, OSF Serban Greceanu, Lehman Brothers
Neil Johannesen, Charles Schwab & Co
DFS V1.1 Overview, Marcie Desmond, OSF
- slides to be made available; highlights include:
- DFS V1.1 to be released as part of DCE V1.1
- Key DFS contents in DCE V1.1:
* code clean-up
* serviceability
* exploit DCE V1.1 features
* find/fix bugs
* performance
* NFS/DFS translator packaged separately
* lower priority items
- DFS work toward overall DCE V1.1 goals:
* Hierarchical cell support
* EPACS (for delegation)
* Regression testing
* Code clean-up (ANSI conformance, macro and header file consistency)
* Code coverage
+ modest goals: cache manager, repserver
+ cache manager: measure coverage for functional tests
+ repserver: shows 40% segment & 80% call coverage against
functional tests shipped with release
* Servicability
+ I18N message catalogs, etc.
+ focus on user space daemons and commands
+ estimated 3-4 staff-months of effort
+ Problem Determination Guide - no update planned
+ Low priority areas?
- scout, gtx
- upclient and upserver not low-priority
- DFS V1.1 Small Resource
* Analyze CPU and resource consumption
* Focus on kernel space
* audience suggestion to look at non-IP protocols
- DFS V1.1 delegation
* would like to "exploit"
- Replace admin lists with ACLs
* RFC to be published
* lower priority task
- Performance
* Currently looking at Bonnie, IOSTONE, and Connectathon(?)
* Port above to reference platforms
* Measure, tune, measure, tune, ...
* Critical areas:
+ Warm cache read/writes
+ Cold cache read/writes
+ ...others (couldn't write fast enough)
- 64-bit feedback -- Jim Mostek, Cray
* Currently, 32-bit clients get confused with files > 2Gby
* Experimental results:
- Create a file of (4 Gby + 10) bytes (on Cray)
- ls(1) shows length of 10 bytes (from 32-bit client)
- read() returns something like 4Kby (on 32-bit client)
- append operation starts writing after first 10 bytes (on 32-bit
client)
- no errors triggered - just data corruption
* Jim has done some work based on the relevant DCE-RFC(s)
* used afs_SetParms() RPC to communicate client's max file size back
to server
* after afs_SetParms, server will return E2BIG to client if
file size exceeds maximum
* commands fail randomly (e.g., ls(1) claims "No such file")
* ...but they fail reasonably (rather than causing data corruption)
Off-line ("slow") Storage - Jim Mostek, Cray Research
- Data files can be migrated off magnetic disks into tape libraries
(robotic or manual) or juke-boxes
- Manual libraries can introduce delays up to 24-hours or more
(e.g., an attempt to fetch a tape from storage when all drives are busy)
- the current DFS implementation "leaves a server thread hanging there
waiting for the tape to be mounted"
- suggestion: tell the client to wait (under NFS, use hard-mount so
that the client eternally retries until it succeeds)
- in cm_analyze, add a check for TKM_TRYAGAIN; prototype code executes a
20-second sleep-and-retry loop
Discussion:
- sleep-and-retry needs to be interruptable at the client end (^C),
tho the server should go ahead, even if request is interrupted
at the client
- exponential back-off strongly recommended on sleep-and-retry loop
to reduce network traffic
- Jim to work with Marcie Desmond to determine process to get changes
into V1.1 (review, submit, test, etc.)
DFS Support of mass storage devices - Jon Goldick, Pittsburgh
Supercomputing Center
- has extended AFS to support non-UNIX file systems
- Pittsburgh Supercomputing Center to embark on a project to extend
this to DFS from the AFS work
- goal: plug any mass storage system into DFS, including mass storage
devices that are accessed from user space drivers (i.e., non-kernel
file systems)
- "Multi-Resident AFS"
* file may reside in multiple places concurrently (e.g., both on-disk
and on-tape)
* allows "infinite" capacity by backing to tape
* transparent access (no application changes)
* dynamic hierarchies of storate systems (ala IEEE) - e.g., aging
and migration
* no modifications to (AFS or DFS) client code
* optional add-on functionality available to client
* "generic I/O interface for easy extension to new storage systems"
* transparent migration among mass storage systems
+ migration done by DFS, not by mass storage systems
+ (roughly like current migration and replication)
* support non-random-access devices
* support write-once, read-never systems (e.g., Salt Mine Storage)
* per-file access history (with analytical tools)
- Additional information: IEEE Mass Storage Symposium XII
- discussion: build into Episode or use VFS+ interface?
(the conclusion, if any, is hard to summarize)
Performance Benchmarks, Andy Kegel, Digital Equipment Corp
- an open discussion to try to find concensus on priorities
- concensus not found, but...
- Recommended reading: "A New Approach to I/O Performance
Evaluation - Self-Scaling I/O Benchmarks, Predicted I/O
Performance", Chen and Patterson (UC-Berkeley), ACM SIGMETRICS,
May '93
- Recommended reading: DCE-RFC-32 and DCE-RFC-33, Instrumentation
- Goals of performance measurement:
(1) Modelling and capacity planning - typ. spans multiple servers
(2) Design analysis for bottlenecks - typ. used by vendors
(e.g., "compile time" and design decisions)
(3) Operational tuning and configuration - typ. single server
(e.g., "knob twisting")
(4) Comparisons across technologies - DFS, AFS, NFS, local,...
- Characteristics of a good benchmark:
* file system bound (not CPU bound)
* wide scalability & self-scalability
* tightly specified (and reproducible)
* portability among file systems
* comparability of results
* parameterized to allow control of benchmark
* produces model data and prediction data
* considerations for DFS -
+ cold cache, hot cache
+ cache hit effects (client buffer cache, client disk cache,
server buffer cache, server disk)
+ parallelism - multithreading on one client & multiple clients
- OSF will specify the planned performance work for DFS V1.1
Wrap-up
- Post-V1.1 processes: lots of questions, not enough announced
information for a meaningful discussion
