Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

The Sun Network File System

No description
by

Dev Ashis Negi

on 23 January 2013

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of The Sun Network File System

The Sun Network Filesystem:
Design, implementation
and Experience Russel Sandberg Presented By:
Dev Ashis Negi CSE710
Wide Area Distributed File System Network File System (NFS) First widely used distributed file system Key features over other file systems include Transparent access to remote filesystem
Portability NFS works over RPC package which uses XDR specification to achieve architecture and OS independent communication The file system interface VFS Interface
vnode Interface Design Goals Machine and OS independence
Easy crash Recovery => Achieved by Stateless protocols in NFS
Transparent Access: File location transparent to client program
Unix Semantics maintained on Unix client
Reasonable performance: as fast as local disk on SCSI interface Basic Design The NFS Protocol The NFS Server The NFS Client Use of synchronous RPC makes transport independent Statelessness: Each call is complete, helps Crash recovery Use of XDR standard gives machine and language independence Separate Mount protocol Stateless=> Commit modified data before returning results Problem: What happens if the server deletes a file after returning its inode number to the client? Soln: Add inode generation id and filesystem id in the superblock NFS interface transparent to applications Mount remote file system to diretctory: Soft and Hard mount File system interface to handle multiple file systems VFS interface + vnode interface File System Interface VFS structure & vnode structure File system & node(Dir., file) related operations One VFS/vnode structure per mounted filesystem/active node Each vnode contains a pointer to 1) parent VFS 2) Mount on VFS VFS contains pointer to the mounted on vnode. Pathname containing ".." can be traversed. root operation: gets root vnode of the mounted filesystem. Allows deallocation of root vnode. Hard Issues 1) File System Naming Multiple names for same filesystem by mounting several times NFS uses basic mounted filesystem on each machine.
User home directories are mounted on /usr/servername.
Tilde expansion supported (~username) 2) Authentication and security Authentication requires mapping from uid and gid to user to be same in all the interacting machines. yellow pages service used to provide flat uid space another solution is to provide network wide identity per user. Yet to implement. Issue with super user access to remote files Server maps user root to user nobody before checking access permission Hard Issues(Cont'd) 3) Concurrent access and file locking NFS has RPC based file locking service called Status Monitor Lock server frees the locked resources by a crashed machine File locking a stateful service File locking issue Concurrent Access Concurrency not guaranteed in NFS. Two clients writing data to a file at same time may corrupt data on long writes 4) Unix Open file semantics Behaviour on deletion or permission change of an open file On delete rename the file and delete later store client credentials at the time of file opening. 5) Time skew Some programs may not work properly because of the time skew between client and server Planned solution: Time synchronization protocol Hard Issues(Cont'd) 6) Performance NFS uses Read ahead and write behind buffer cache cache for file attributes and directory names UDP packet size increased to 9000 Performance optimization in NFS reduced data copy overhead by implementing new XDR type that translates directly to/from kernel buffers Other issues: write is slow because of synchronous call
each getattr makes one RPC(Not a local access issue with stat) RFS VS NFS
Works only with System V.3 based Unix systems Uses special transport protocols. Not flexible to use others. Currently uses UDP. Flexible to use others works with 5 OSes and 16 different vendor Hardwares No crash recovery since costly. No crash recovery required in NFS Uses uid mapping table for user authentication Assumes uniform uid across network and uses Yellow page service Support 100% UNIX semantics Unix semantics not fully supported RFS has not been released In operation for 1 year at the time of writing this paper Good for small network of machines running System V.3 Good for large heterogeneous networks What is NFS Versions and variations First revision, NFSv2, was published in 1985. It exports basic POSIX 32-bit filesystems => Can read upto first 2GB of a file NFSv3, was published in 1994 Support for 64-bit file sizes and offsets => Handle file larger than 2GB Improved write performance with asynchronous write Additional file attributes in replies => saves time to re-fetch them Added READDIRPLUS operation => returns file attributes and handles in Dir scan Added support for TCP as transport protocol => NFS over WAN became more feasible NFS Version 4 Added features The Security Model RPCSEC_GSS framework used to extend basic RPC security Mandates the use of strong RPC security flavors In-band security negotiation using client query Uses character strings instead of integer for user id and group id. authentication + integrity checksum + encryption Other mandated security frameworks: Kerberose V5 & LIPKEY The COMPOUND procedure The COMPOUND procedure groups multiple related operations into a single RPC packet. Evaluation of operations stop on first error Other changes NFS Version 4 (cont'd) Mount protocol & NLM protocol removed. NFS 4 is a single protocol OPEN and CLOSE operations included Combines file lookup, creation and share semantics File locking is integrated to NFS 4 Lease based model File migration and replication is supported in NFS4 File locking and delegation makes NFS4 stateful Extensions to NFS4 Parallel Network File System NFS4.1 introduces a method of data access parallelism
Separates metadata of a filesystem from the =>Provision of Data Striping, RAID location of file data Extensions to NFS4(cont'd) NFS in global Wide area networks(WANs) Main Concerns: Security, Latency , Error and loss recovery WebNFS features File accessing across the internet Enhanced download performance Error and Crash Recovery Works through firewall Optimized to use bandwidth efficiently NFS Present and Future NFSV4.1 adds support for pNFS and NFS over wide area.
pNFS and NFS over WAN are still evolving. NFSv4.2 is due for release Future enhancement may include Proxy NFS file services References The Sun Network file system: Design, implementation and experience:
http://www.cse.buffalo.edu/faculty/tkosar/cse710/papers/nfs.pdf http://www.ietf.org/rfc/rfc3530.txt http://www.pnfs.com/ www.cs.rice.edu/~gw4314/lectures/NFS.ppt http://www.pnfs.com/ QUESTIONS Support for multi-realm security
Full transcript