network file systems n.
Skip this Video
Download Presentation
Network File Systems

Loading in 2 Seconds...

play fullscreen
1 / 42

Network File Systems - PowerPoint PPT Presentation

  • Uploaded on

Network File Systems. Victoria Krafft CS 614 10/4/05. General Idea. People move around Machines may want to share data Want a system with: No new interface for applications No need to copy all the data No space consuming version control. Network File Systems.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Network File Systems' - adonai

Download Now An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
network file systems

Network File Systems

Victoria Krafft

CS 614


general idea
General Idea
  • People move around
  • Machines may want to share data
  • Want a system with:
    • No new interface for applications
    • No need to copy all the data
    • No space consuming version control
network file systems1
Network File Systems

Diagram from

a brief history
A Brief History
  • Network File System (NFS) developed in 1984
    • Simple client-server model
    • Some problems
  • Andrew File System (AFS) developed in 1985
    • Better performance
    • More caching client-side
  • SFS 1999
    • NFS can be run on untrusted networks
lingering issues
Lingering Issues
  • Central server is a major bottleneck
  • All choices still require lots of bandwidth
  • LANs getting faster & lower latency
    • Remote memory faster than local disk
    • ATM faster with more nodes sending data
cooperative caching
Cooperative Caching
  • Michael D. Dahlin, Randolph Y. Wang, Thomas E. Anderson, and David A. Patterson in 1994
  • ATM, Myrinet provide faster, low-latency network
  • This makes remote memory 10-20x faster than disk
  • Want to get data from memory of other clients rather than server disk
cooperative caching1
Cooperative Caching
  • Data can be found in:
    • Local memory
    • Server memory
    • Other client memory
    • Server disk
  • How should we distribute cache data?
design decisions
Design Decisions


Coop. Cache?




Cache Entries?

Direct Client


No Coordination








Block Location?




Any Client


Cent. Coord


direct client cooperation
Direct Client Cooperation
  • Active clients use idle client memory as a backing store
  • Simple
  • Don’t get info from other active clients
greedy forwarding
Greedy Forwarding
  • Each client manages its local cache greedily
  • Server stores contents of client caches
  • Still potentially large amounts of data duplication
  • No major cost for performance improvements
centrally coordinated caching
Centrally Coordinated Caching
  • Client cache split into two parts – local and global
n chance forwarding
N-Chance Forwarding
  • Clients prefer to cache singlets, blocks stored in only one client cache.
  • Instead of discarding a singlet, set recirculation count to n and pass on to a random other client.

Variation in Response Time

with Client Cache Size

Variation in Response Time

with Network Latency

simulation results
Simulation results

Average read response time

Sever load

simulation results1
Simulation results



  • N-Chance forwarding close to best possible performance
  • Requires clients to trust each other
  • Requires fast network
serverless nfs
Serverless NFS
  • Thomas E. Anderson, Michael D. Dahlin, Jeanna M. Neefe, David A. Patterson, Drew S. Roselli, and Randolph Y. Wang in 1995
  • Eliminates central server
  • Takes advantage of ATM and Myrinet
starting points
Starting points
  • RAID: Redundancy if nodes leave or fail
  • LFS: Recovery when system fails
  • Zebra: Combines LFS and RAID for distributed systems
  • Multiprocessor Cache Consistency: Invalidating stale cache info
to eliminate central servers
To Eliminate Central Servers
  • Scaleable distributed metadata, which can be reconfigured after a failure
  • Scalable division into groups for efficient storage
  • Scalable log cleaning
how it works
How it works
  • Each machine has one or more roles:
    • Client
    • Storage Server
    • Manager
    • Cleaner
  • Management split among metadata managers
  • Disks clustered into stripe groups for scalability
  • Cooperative caching among clients
  • xFS is a prototype of the serverless network file system
  • Lacks a couple features:
    • Recovery not completed
    • Doesn’t calculate or distribute new manager or stripe group maps
    • No distributed cleaner
file write
File Write
  • Buffered into segments in local memory
  • Client commits to storage
  • Client notifies managers of modified blocks
  • Managers update index nodes & imaps
  • Periodically, managers log changes to stable storage
distributing file management
Distributing File Management
  • First Writer – management goes to whoever created the file

*does not include all local hits

  • Segment utilization maintained by segment writer
  • Segment utilization stored in s-files
  • Cleaning controlled by stripe group leader
  • Optimistic Concurrency control resolves cleaning / writing conflicts
  • Several steps are O(N2), but can be run in parallel

Steps For Recovery

xfs performance
xFS Performance

NFS max with 2 clients

NFS max with 2 clients

AFS max with 32 clients

AFS max with 12 clients

Aggregate Bandwidth

Writing 10MB files

Aggregate Bandwidth

Reading 10MB files

xfs performance1
xFS Performance

Average time to complete the Andrew benchmark,

varying the number of simultaneous clients

system variables
System Variables

Aggregate Large-Write Bandwidth with

Different Storage Server Configurations

Variation in Average Small File

Creation Speed with more Managers

possible problems
Possible Problems
  • System relies on secure network between machines, and trusted kernels on distributed nodes
  • Testing done on Myrinet
low bandwidth nfs
Low-Bandwidth NFS
  • Want efficient remote access over slow or wide area networks
  • File systems better than CVS, copying all data over
  • Want close-to-open consistency
  • Large client cache containing user’s working set of files
  • Don’t send all the data – reconstitute files from previous data, and only send changes
file indexing
File indexing
  • Non-overlapping chunks between 2K and 64K
  • Broken up using 48 byte Rabin fingerprints
  • Identified by SHA-1 hash, indexing on first 64 bits
  • Stored in database, recomputed before use to avoid synchronization issues
  • Security infrastructure from SFS
  • Whole file caching
  • Retrieve from server on read unless valid copy in cache
  • Write back to server when file closed
  • LBFS server accesses file system as an NFS client
  • Server creates trash directory for temporary files
  • Server inefficient when files overwritten or truncated, which could be fixed by lower-level access.
  • Client uses xfs driver
bandwidth consumption
Bandwidth consumption

Much higher bandwidth for first build

  • New technologies open up new possibilities for network file systems
  • Cost of increased traffic over Ethernet may cause problems for xFS, cooperative caching.