Nfs version 4 protocol presentation
Upcoming SlideShare
Loading in...5
×
 

Nfs version 4 protocol presentation

on

  • 408 views

 

Statistics

Views

Total Views
408
Views on SlideShare
408
Embed Views
0

Actions

Likes
1
Downloads
19
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Nfs version 4 protocol presentation Nfs version 4 protocol presentation Presentation Transcript

  • NETWORK FILE SYSTEM - NFSVERSION 4 PROTOCOLBY: MOHAMMED A. EL-SHEIKH – 120101700AHMED AHEL - 1201014581
  • AGENDA• 1. INTRODUCTION• 2. OVERVIEW• 3. NFS VERSION 4 GOALS• 4. BASIC NFS ARCHITECTURE• 5. LOCKING• 6. SECURITY ERROR• 7. FILE HANDLES• 8. FILE ATTRIBUTES• 9. TIME ACCESS• 10. REFERENCES2
  • • 1. INTRODUCTIONTHE NETWORK FILE SYSTEM (NFS) VERSION 4 IS A DISTRIBUTED FILE SYSTEMPROTOCOL WHICH OWES HERITAGE TO NFS PROTOCOL VERSION 2, RFC1094, AND VERSION 3, RFC 1813.UNLIKE EARLIER VERSIONS, THE NFS VERSION 4 PROTOCOL SUPPORTSTRADITIONAL FILE ACCESS , STRONG SECURITY.3
  • 2. OVERVIEWWHAT IS NFS 4 ??• NFS, WAS DEVELOPED BY SUN MICROSYSTEMS TOGETHER WITH INTERNET ENGINEERING TASKFORCE (IETF).• IETF DEVELOPS AND PROMOTES INTERNET STANDARDS, COOPERATING CLOSELY WITH THEW3C AND ISO/IEC STANDARDS BODIES.• THE DEFINITION OF THE NFS VERSION 4 PROTOCOL IS RFC 3010.4
  • 3. NFS VERSION 4 GOALSIT RETAINS THE ESSENTIAL CHARACTERISTICS OF PREVIOUSVERSIONS LIKE DESIGN FOR EASY RECOVERY , INDEPENDENT OFTRANSPORT PROTOCOLS ,OPERATING SYSTEMS AND FILE SYSTEMSSIMPLICITY, AND GOOD PERFORMANCE.THE NFS VERSION 4 REVISION HAS THE FOLLOWING GOALS:1) IMPROVED ACCESS AND GOOD PERFORMANCE ON THE INTERNET.2) STRONG SECURITY WITH NEGOTIATION BUILT INTO THE PROTOCOL.3) EXTENSIBILITY OF THE PROTOCOL 5
  • GENERAL PROPERTIES• THE NFS VERSION 4 PROTOCOL IS STATEFUL.• NFS IS BUILT ON TOP OF THE ONC REMOTE PROCEDURE PROTOCOL.• ALSO USES XDR.• THE EXTERNAL DATA REPRESENTATION (XDR) ENABLES HETEROGENEOUS OPERATION BYDEFINING A CANONICAL DATA ENCODING OVER THE WIRE.6
  • 4. BASIC NFS ARCHITECTURE7
  • THE COMPOUND PROCEDURE• THE COMPOUND PROCEDURE GROUPS MULTIPLE RELATED OPERATIONS INTO A SINGLERPC PACKET.• THE RPC RESPONSE TO A COMPOUND PROCEDURE CONTAINS THE REPLIES TO ALL THEOPERATIONS.• EVALUATION OF THE OPERATIONS STOPS ON FIRST ERROR.• IT MAY BE UNWISE TO ATTEMPT GROUPING UNRELATED OPERATIONS INTO A SINGLECOMPOUND PROCEDURE.8
  • 9
  • 5. LOCKING• NFS 4 LOCKING IS SIMILAR TO THE NETWORK LOCK MANAGER (NLM)PROTOCOL.• NLM IS USED WITH NFS VERSIONS 2 AND 3.• LOCKING IS TIGHTLY COUPLED TO THE NFS 4 PROTOCOL.• BETTER SUPPORT DIFFERENT OPERATING SYSTEM SEMANTICS AND ERRORRECOVERY.10
  • • CLIENT AND SERVER MUST SUPPORT A MINIMUM SET OF SECURITY.• THE NFS CLIENT WILL START ITS COMMUNICATION WITH THE SERVER WITH ONE OF THE MINIMAL SECURITYTRIPLES.• DURING COMMUNICATION WITH THE SERVER, THE CLIENT MAY RECEIVE AN NFS ERROR OFNFS4ERR_WRONGSEC.• THIS ERROR ALLOWS THE SERVER TO NOTIFY THE CLIENT THAT THE SECURITY TRIPLE CURRENTLY BEINGUSED IS NOT APPROPRIATE FOR ACCESS TO THE SERVERS FILE SYSTEM RESOURCES.• THE CLIENT IS THEN RESPONSIBLE FOR DETERMINING WHAT SECURITY TRIPLES ARE AVAILABLE AT THESERVER AND CHOOSE ONE WHICH IS APPROPRIATE FOR THE CLIENT.6. SECURITY ERROR11
  • 7. FILE HANDLES• A FILEHANDLE, IS A PER SERVER UNIQUE IDENTIFIER FOR A FILE SYSTEM OBJECT.• FILEHANDLES THAT ARE EQUAL REFER TO THE SAME FILE SYSTEM OBJECT.• BUT NO ASSUMPTIONS CAN BE MADE BY THE CLIENT IF THE FILEHANDLES DIFFER.• THE CURRENT FILEHANDLE IS USED BY SUBSEQUENT OPERATIONS IN A SINGLE COMPOUNDPROCEDURE.• GETFH OPERATION TO FETCH THE CURRENT FILEHANDLE.12
  • OBTAINING THE FIRST FILEHANDLE• THE OPERATIONS OF THE NFS PROTOCOL ARE DEFINED IN TERMS OF ONE OR MOREFILEHANDLES. THEREFORE, THE CLIENT NEEDS A FILEHANDLE TO INITIATE COMMUNICATION WITHTHE SERVER.• WITH THE NFS VERSION 2 PROTOCOL [RFC1094] AND THE NFS VERSION 3 PROTOCOL[RFC1813], THERE EXISTS AN ANCILLARY PROTOCOL TO OBTAIN THIS FIRST FILEHANDLE.• THE MOUNT PROTOCOL, RPC PROGRAM NUMBER 100005, PROVIDES THE MECHANISM OFTRANSLATING A STRING BASED FILESYSTEM PATH NAME TO A FILEHANDLE, WHICH CAN THEN BEUSED BY THE NFS PROTOCOLS.13
  • ROOT FILEHANDLE• THE FIRST OF THE SPECIAL FILEHANDLES IS THE ROOT FILEHANDLE. THE ROOT FILEHANDLE ISTHE "CONCEPTUAL" ROOT OF THE FILESYSTEM NAME SPACE AT THE NFS SERVER.• THE CLIENT USES OR STARTS WITH THE ROOT FILEHANDLE BY EMPLOYING THE PUTROOTFHOPERATION. THE PUTROOTFH OPERATION INSTRUCTS THE SERVER TO SET THE "CURRENT"FILEHANDLE TO THE ROOT OF THE SERVERS FILE TREE.• ONCE THIS PUTROOTFH OPERATION IS USED, THE CLIENT CAN THEN TRAVERSE THE ENTIRETYOF THE SERVERS FILE TREE WITH THE LOOKUP OPERATION.14
  • PUBLIC FILEHANDLE• PUBLIC FILEHANDLES ARE NORMALLY CREATED BY THE SERVER AND USED TO IDENTIFY UNIQUELYA PARTICULAR FILE OR DIRECTORY ON THE SERVER.• THE CLIENT DOES NOT NORMALLY CREATE FILEHANDLES OR HAVE ANY KNOWLEDGE OF THECONTENTS OF A FILEHANDLE. THE SERVER IS RESPONSIBLE FOR THIS BINDING. IT MAY BE THATTHE PUBLIC FILEHANDLE AND THE ROOT FILEHANDLE REFER TO THE SAME FILESYSTEM OBJECT.• HOWEVER, IT IS UP TO THE ADMINISTRATIVE SOFTWARE AT THE SERVER AND THE POLICIES OFTHE SERVER ADMINISTRATOR TO DEFINE THE BINDING OF THE PUBLIC FILEHANDLE AND SERVERFILESYSTEM OBJECT.• THE SERVER CREATE PUBLIC FILEHANDLE VIA THE PUTPUBFH OPERATION.15
  • 8. FILE ATTRIBUTES• TO MEET THE REQUIREMENTS OF EXTENSIBILITY AND INCREASED INTEROPERABILITY WITH NON-UNIX PLATFORMS, ATTRIBUTES MUST BE HANDLED IN A FLEXIBLE MANNER.• THE NFS VERSION 3-FATTR3 STRUCTURE CONTAINS A FIXED LIST OF ATTRIBUTES THAT NOT ALLCLIENTS AND SERVERS ARE ABLE TO SUPPORT OR CARE ABOUT.• THE FATTR3 STRUCTURE CANNOT BE EXTENDED AS NEW NEEDS ARISE AND IT PROVIDES NO WAYTO INDICATE NON-SUPPORT.• WITH THE NFS VERSION 4 PROTOCOL, THE CLIENT IS ABLE QUERY WHAT ATTRIBUTES THE SERVERSUPPORTS AND CONSTRUCT REQUESTS WITH ONLY THOSE SUPPORTED ATTRIBUTES (OR A SUBSETTHEREOF).16
  • FILE ATTRIBUTES• TO THIS END, ATTRIBUTES ARE DIVIDED INTO THREE GROUPS: MANDATORY, RECOMMENDED, ANDNAMED.• BOTH MANDATORY AND RECOMMENDED ATTRIBUTES ARE SUPPORTED IN THE NFS VERSION 4PROTOCOL BY A SPECIFIC AND WELL-DEFINED ENCODING AND ARE IDENTIFIED BY NUMBER.• THEY ARE REQUESTED BY SETTING A BIT IN THE BIT VECTOR SENT IN THE GETATTR REQUEST; THESERVER RESPONSE INCLUDES A BIT VECTOR TO LIST WHAT ATTRIBUTES WERE RETURNED IN THERESPONSE.• NEW MANDATORY OR RECOMMENDED ATTRIBUTES MAY BE ADDED TO THE NFS PROTOCOLBETWEEN MAJOR REVISIONS BY PUBLISHING A STANDARDS-TRACK RFC THAT ALLOCATES A NEWATTRIBUTE NUMBER VALUE AND DEFINES THE ENCODING FOR THE ATTRIBUTE.17
  • FILE ATTRIBUTES• NAMED ATTRIBUTES ARE ACCESSED BY THE NEW OPENATTR OPERATION, WHICH ACCESSES AHIDDEN DIRECTORY OF ATTRIBUTES ASSOCIATED WITH A FILE SYSTEM OBJECT.• OPENATTR TAKES A FILEHANDLE FOR THE OBJECT AND RETURNS THE FILEHANDLE FOR THEATTRIBUTE HIERARCHY.• THE FILEHANDLE FOR THE NAMED ATTRIBUTES IS A DIRECTORY OBJECT ACCESSIBLE BYLOOKUP OR READDIR AND CONTAINS FILES WHOSE NAMES REPRESENT THE NAMEDATTRIBUTES AND WHOSE DATA BYTES ARE THE VALUE OF THE ATTRIBUTE.18
  • MANDATORY ATTRIBUTES• EVERY NFS VERSION 4 CLIENT AND SERVER MUST SUPPORT THESE IN ORDER TO ENSURE AMINIMUM LEVEL OF INTEROPERABILITY.• THE SERVER MUST STORE AND RETURN THESE ATTRIBUTES AND THE CLIENT MUST BE ABLE TOFUNCTION WITH AN ATTRIBUTE SET LIMITED TO THESE ATTRIBUTES.• WITH JUST THE MANDATORY ATTRIBUTES, SOME CLIENT FUNCTIONALITY MAY BE IMPAIRED ORLIMITED IN SOME WAYS.• A CLIENT MAY ASK FOR ANY OF THESE ATTRIBUTES TO BE RETURNED BY SETTING A BIT IN THEGETATTR REQUEST AND THE SERVER MUST RETURN THEIR VALUE.19
  • RECOMMENDED ATTRIBUTES• THESE ATTRIBUTES ARE UNDERSTOOD WELL ENOUGH TO WARRANT SUPPORT IN THE NFSVERSION 4 PROTOCOL. HOWEVER, THEY MAY NOT BE SUPPORTED ON ALL CLIENTS ANDSERVERS.• A CLIENT MAY ASK FOR ANY OF THESE ATTRIBUTES TO BE RETURNED BY SETTING A BIT IN THEGETATTR REQUEST BUT MUST HANDLE THE CASE WHERE THE SERVER DOES NOT RETURN THEM.• A CLIENT MAY ASK FOR THE SET OF ATTRIBUTES THE SERVER SUPPORTS AND SHOULD NOTREQUEST ATTRIBUTES THE SERVER DOES NOT SUPPORT.• A SERVER SHOULD BE TOLERANT OF REQUESTS FOR UNSUPPORTED ATTRIBUTES AND SIMPLY NOTRETURN THEM RATHER THAN CONSIDERING THE REQUEST AN ERROR20
  • RECOMMENDED ATTRIBUTES• IT IS EXPECTED THAT SERVERS WILL SUPPORT ALL ATTRIBUTES THEY COMFORTABLY CAN ANDONLY FAIL TO SUPPORT ATTRIBUTES, WHICH ARE DIFFICULT TO SUPPORT IN THEIR OPERATINGENVIRONMENTS.• A SERVER SHOULD PROVIDE ATTRIBUTES WHENEVER THEY DO NOT HAVE TO "TELL LIES" TO THECLIENT. FOR EXAMPLE, A FILE MODIFICATION TIME EITHER SHOULD BE AN ACCURATE TIME ORSHOULD NOT BE SUPPORTED BY THE SERVER.• THIS WILL NOT ALWAYS BE COMFORTABLE TO CLIENTS BUT THE CLIENT IS BETTER POSITIONEDDECIDE WHETHER AND HOW TO FABRICATE OR CONSTRUCT AN ATTRIBUTE OR WHETHER TO DOWITHOUT THE ATTRIBUTE.21
  • NAMED ATTRIBUTES• THESE ATTRIBUTES ARE NOT SUPPORTED BY DIRECT ENCODING IN THE NFS VERSION 4 PROTOCOLBUT ARE ACCESSED BY STRING NAMES RATHER THAN NUMBERS AND CORRESPOND TO ANUNINTERPRETED STREAM OF BYTES, WHICH ARE STORED WITH THE FILESYSTEM OBJECT.• THE NAME SPACE FOR THESE ATTRIBUTES MAY BE ACCESSED BY USING THE OPENATTR OPERATION.• THE OPENATTR OPERATION RETURNS A FILEHANDLE FOR A VIRTUAL "ATTRIBUTE DIRECTORY" ANDFURTHER PERUSAL OF THE NAME SPACE MAY BE DONE USING READDIR AND LOOKUPOPERATIONS ON THIS FILEHANDLE.• NAMED ATTRIBUTES MAY THEN BE EXAMINED OR CHANGED BY NORMAL READ AND WRITE ANDCREATE OPERATIONS ON THE FILEHANDLES RETURNED FROM READDIR AND LOOKUP.22
  • NAMED ATTRIBUTES• IT IS RECOMMENDED THAT SERVERS SUPPORT ARBITRARY NAMED ATTRIBUTES. A CLIENT SHOULDNOT DEPEND ON THE ABILITY TO STORE ANY NAMED ATTRIBUTES IN THE SERVERS FILESYSTEM.• IF A SERVER DOES SUPPORT NAMED ATTRIBUTES, A CLIENT WHICH IS ALSO ABLE TO HANDLETHEM SHOULD BE ABLE TO COPY A FILES DATA AND META-DATA WITH COMPLETETRANSPARENCY FROM ONE LOCATION TO ANOTHER; THIS WOULD IMPLY THAT NAMESALLOWED FOR REGULAR DIRECTORY ENTRIES ARE VALID FOR NAMED ATTRIBUTE NAMES ASWELL.23
  • 9. TIME ACCESS• THE TIME_ACCESS ATTRIBUTE REPRESENTS THE TIME OF LAST ACCESS TO THE OBJECT BY A READTHAT WAS SATISFIED BY THE SERVER.• THE NOTION OF WHAT IS AN "ACCESS" DEPENDS ON SERVERS OPERATING ENVIRONMENTAND/OR THE SERVERS FILESYSTEM SEMANTICS.• FOR EXAMPLE, FOR SERVERS OBEYING POSIX SEMANTICS, TIME_ACCESS WOULD BE UPDATEDONLY BY THE READLINK, READ, AND READDIR OPERATIONS AND NOT ANY OF THEOPERATIONS THAT MODIFY THE CONTENT OF THE OBJECT. OF COURSE, SETTING THECORRESPONDING TIME_ACCESS_SET ATTRIBUTE IS ANOTHER WAY TO MODIFY THE TIME_ACCESSATTRIBUTE.24
  • TIME ACCESS• WHENEVER THE FILE OBJECT RESIDES ON A WRITABLE FILESYSTEM, THE SERVER SHOULD MAKEBEST EFFORTS TO RECORD TIME_ACCESS INTO STABLE STORAGE.• HOWEVER, TO MITIGATE THE PERFORMANCE EFFECTS OF DOING SO, AND MOST ESPECIALLYWHENEVER THE SERVER IS SATISFYING THE READ OF THE OBJECTS CONTENT FROM ITS CACHE,THE SERVER MAY CACHE ACCESS TIME UPDATES AND LAZILY WRITE THEM TO STABLE STORAGE.IT IS ALSO ACCEPTABLE TO GIVE ADMINISTRATORS OF THE SERVER THE OPTION TO DISABLETIME_ACCESS UPDATES.25
  • 10. REFERENCESWEBSITE: HTTP://WWW.HJP.AT• URL: HTTP://WWW.HJP.AT/DOC/RFC/RFC3530.HTML• VISITED DATE: 6.5.2013 - 9:30 PMWEBSITE: HTTP://DATATRACKER.IETF.ORG• URL: HTTP://DATATRACKER.IETF.ORG/WG/NFSV4/CHARTER/• VISITED DATE: 7.5.2013 - 2:30 PMWEBSITE: HTTP://WWW.IAPS.COM• URL: HTTP://WWW.IAPS.COM/NFSV4.HTML• VISITED DATE: .5.2013 - :30 PM26
  • WITHOUT QUESTIONS !!27