GLOBAL EDGE SOFTWERE LTD1 R EMOTE F ILE S HARING - Ardhanareesh Aradhyamath.

GLOBAL EDGE SOFTWERE LTD 1

REMOTE FILE SHARING

- Ardhanareesh Aradhyamath


The arc of the presentation

Introduction distributed file systemStateful and stateless operation RFS architecture RFS Implementation Client-side cachingCache consistency Conclusion


Introduction Distributed file system

• A Distributed File System is simply a classical model of a file system distributed across multiple machines. The purpose is to promote sharing of dispersed files.

• This is an area of active research interest today.• The resources on a particular machine are local to

itself. Resources on other machines are remote.• A file system provides a service for clients. The

server interface is the normal set of file operations: create, read, etc. on files.


Properties of Distributed File Systems

•Network transparency.

•Location transparency.

• Location independence.

• User mobility.

• Fault tolerance.

• Scalability.

• File Mobility


Design Considerations

Different Distributed File Systems can be compared according to how they deal with these issues:

• Name Space.

• Stateful or stateless operation.

• Semantics of sharing.

• Remote access methods.


Remote File Sharing (RFS)

• Introduced by AT&T.

• RFS uses the client-server model.

• The design goal is to provide transparent access to remote files by preserving UNIX semantics.

• RFS can be used both LANs and WANs.


RFS Architecture

• RFS based on client server model.• Server advertises the directories, and the client

mount them.• RFS is completely stateful architecture, which

necessary to correctly provide Unix open file semantics.

• RFS uses a reliable, virtual circuit transport service such as TCP/IP. A virtual circuit is established between a client and server during the first mount operation.


Client application

System call interface

RFS client code

Local disk

RFS server code

stream stream

Virtual circuit

Client Server

Communication in RFS


Remote Message Protocol

RFS uses a remote system call model. The server creates the clients environment executes

the system call. The result is send back to the clients system call and

client interprets the result. This implementation was called the RFS1.0 protocol.

SVR4 introduces a new protocol RFS2.0. It provides a set of requests that mapped vnode and

vfs operation, and provides integration with vnode/vfs interface.


Stateful Operation

• Server maintains state about the clients.• The server records which file has been opened by the

client, and increments the reference counts.• Server keep track of file/record locks.• Server also maintains a table of all clients that have

mounted its file system.• The table stores the client Internet address, the

mounted file system and parameters of the virtual circuit connection.


Remote Mount

• An RFS server can advertise a directory using the advfs system call.

• The arguments to advfs are path name of exported directory, the resource name associated with the directory and a list of client machines authorized to the resource.


vnode

ufsnode

v_data

v_op

Resource list head

Ptr to auth clients

Root vnode ptr

Resource name

Ptr to mnt list

Mount list for resource

List of authorized clients

Resource entry

RFS resource list


1

1

2

2

33

Server registers name with name server

Client gets server location from name server

Client sends mount request to server

Name server

RFS server

RFS Client

Mounting an RFS file system


Continued …

• The server invokes the adv(1) command to register its its advertised resource with the name server. Some times later, a client mounts an RFS resource by a command

• mount -d <RNEME> /mnt • Mount system call sends mount request to server,

passing the symbolic resource name.• The response contains mount ID.


Continued …

• When client receive mount response it sets up the vfs entry, vnode for root directory of resource.

• V_data field of an RFS vnode points to a data structure called a send descriptor, which contains information about the virtual circuit as well as a file handle.

• The mount operation initiates a connection to a deamon process on the server.

• Once the connection established the client and server negotiate the run time parameters.


RFS Clients and Servers

The client can access an RFS file either through its path name or through file descriptor.

If mount point comes while traversing. Server returns handle to vnode which client stores in

private data of vnode. The vnode operations invokes RFS client functions. Then RFS server runs daemon process, which listen

for the incoming requests and services each request before attempting next.

The RFS daemon may sleep if they need to wait for resources and scheduled just like normal processes.


Client Server

RFS send descriptorLocal vnode of file

vnode of exported directory

V_node

. . .

V_node

. . .

V_node

. . .

vnode

vnode

vnode

Vfs_data

. . .

Struct vfs

Mount_id

. . .

Struct rf_vfs

Virtual circuit file handler

Resource list

RFS data structures


Crash Recovery

Client and server need to detect and handle the failures i.e.

when either machine crashes or virtual path between them breaks.

Client crashes: server must undo all states related to that client i.e.

1. Decrements the inode reference count. 2. releases any reader/writer locks on named pipes in

use by the client. 3. releases any file/record locks held by the client.


Continued...

Server crash: All client processes waiting for responses from the

server are woken up. System calls return an ENOLINK error message. All RFS inode referring to files on that server are

flagged such that subsequent operations on them return an error.


Other Issues

Process pool: Whenever a client request arrives and all the server processes are busy, it creates a new process. This pool has upper bound, and the last process is not allowed to sleep.

Remote signal: Unix allows a signal to abort a system call, and this facility must be extended to RFS environments.

Data transfer: For a local read or write system call, the copyin() and copyout() routines move data.


Client-side Caching

Client cache is activated at the mount time. The cache is strictly write-through. Clients send all

writes to server immediately, after updating the local cached copy.

A read system call returns cached data if and if all the data requested is available in the cache.

If data not in the local cache then the client fetches all the data from server.

Buffers are reused in least recently used order.


Cache Consistence

Any modification to a file, either by a user on the server, or by one of the clients, invalidates the cached copies on all other clients.

Consistence protocols are only required for files that are shared by multiple files.

When server receive the first write request for a file open on more than one client.


CLIENT C1

SERVER CLIENT C2

Write to file1

Sends message to server

Has opened file1

time

Returns from write call

Block write,

sends invalidate

message to C2

Complete write,

Responds to C1

Has opened file1

Invalidates cache

entries for files1

Replay to server

RFS cache consistency algorithm


Continued..

Another case there may be some clients who closed the file, if opened again.

Solution for this is version number with each file which is incremented each time the file is modified.

Server return the version number in the response to each open request.

Its will be compared with old one, if mismatch then flush all data blocks of that file.

Conclusion

RFS provides Unix semantics and also provides device sharing.As it uses stateful operation the network traffic is reduced.The strong cache consistency model guarantee that a read always returns data that is identical to server image of the file at the time of access.So Reliability and efficiency is more.


Thank you.

GLOBAL EDGE SOFTWERE LTD1 R EMOTE F ILE S HARING - Ardhanareesh Aradhyamath.

Documents

Transcript of GLOBAL EDGE SOFTWERE LTD1 R EMOTE F ILE S HARING - Ardhanareesh Aradhyamath.