Scribd
Upload
63 views

DFS Architecture

The document describes a file service architecture with three main components: a flat file service, directory service, and client module. The flat file service provides core file operations like create, read, write, and delete. It assigns unique file identifiers. The directory service maps file names to identifiers and provides operations for lookup, adding/removing names. The client module runs on each client computer and provides an API for file access using remote procedure calls to the server services. It can also implement caching. This architecture allows stateless and fault-tolerant file access in a distributed system.

Uploaded by

Rahul S.Kumar
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
63 views

DFS Architecture

The document describes a file service architecture with three main components: a flat file service, directory service, and client module. The flat file service provides core file operations like create, read, write, and delete. It assigns unique file identifiers. The directory service maps file names to identifiers and provides operations for lookup, adding/removing names. The client module runs on each client computer and provides an API for file access using remote procedure calls to the server services. It can also implement caching. This architecture allows stateless and fault-tolerant file access in a distributed system.

Uploaded by

Rahul S.Kumar
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 19

Module 4- File Service Architecture

By
Sreedevi T R
Assistant Professor
Dept of CSE
RSET
File service architecture
• Providing access to files is obtained by structuring the file
service as three components:

• Flat file service


• Directory service
• Client module
File service architecture
Client computer Server computer

Application Application Directory service


program program

Flat file service

Client module

3
Client module
• Processes that invoke a service using set of operations that
forms its client interface
• Run on each client computer
• API for file access, one per client computer
• Client module also holds information about network location of
flat file & directory server.
• Client module can play an important role in achieving
satisfactory performance through the implementation of a
cache of recently used file blocks at the client.
• Clients talk to server using RPC:

• Use RPC to forward every file system request; remote server executes
each request as a local request; server responds back with result
Flat File Service
• Concerned with implementing operations on the concepts of
files.
What operations should be provided?
• create a file and allocate a file identifier
• delete a file
• read from a file identified by a file identifier
• write a number of bytes to a file identified by a file identifier

6
Contd..
• Unique File Identifiers (UFIDs) are used to refer to files in all
requests for flat file service operations.
• Responsibilities of file and directory service is based upon UFID
(long sequence of bits so each file has UFID which is unique in DS).
• UFIDs are long sequences of bits chosen so that each file has a
UFID that is unique among all of the files in a distributed system.
• When the flat file service receives a request to create a file, it
generates a new UFID for it and returns the UFID to the requester.
Contd..
• This is the RPC interface used by client modules.
• A FileId is invalid if the file that it refers to is not present in the
server processing the request or if its access permissions are
inappropriate for the operation requested.
• All of the procedures in the interface except Create throw
exceptions if the FileId argument contains an invalid UFID or the
user doesn’t have sufficient access rights.
Flat file service operations

Read(FileId, i, n) -> Data If 1 ≤ i ≤ Length(File): Reads a sequence of up to n items


— throwsBadPosition from a file starting at item i and returns it in Data.
Write(FileId, i, Data) If 1 ≤ i ≤ Length(File)+1: Writes a sequence of Data to a
— throwsBadPosition file, starting at item i, extending the file if necessary.
Create() -> FileId Creates a new file of length 0 and delivers a UFID for it.
Delete(FileId) Removes the file from the file store.
GetAttributes(FileId) -> Attr Returns the file attributes for the file.
SetAttributes(FileId, Attr) Sets the file attributes (only those attributes that are not
shaded in Figure 8.3).
The interface to our flat file service differs from the UNIX file
system interface mainly for reasons of fault tolerance:
1. Repeatable operations:
With the exception of Create, the operations are idempotent,
allowing the use of at-least-once RPC semantics – clients may
repeat calls to which they receive no reply. Repeated execution of
Create produces a different new file for each call.
2. Stateless servers:
The interface is suitable for implementation by stateless
servers. Stateless servers can be restarted after a failure and
resume operation without any need for clients or the server to
restore any state.
3. Access Control
• UNIX checks access rights when a file is opened
– Subsequent checks during read/write are not necessary
• Distributed environment
– Server has to check
– Stateless approaches
1. Access check once when UFID is issued
-> Client gets an encoded "capability"
-> Capability is submitted with each subsequent request
2. access check for each request.
-> More common
Directory Service
• Provides mapping between text names for the files and their
UFIDs.
• Clients may obtain the UFID of a file by quoting its text name to
directory service.
• The directory service provides the functions needed to generate
directories, to add new file names to directories and to obtain
UFIDs
from directories.
• It is a client of the flat file service; its directory files are stored in
files of
the flat file service. 12
Directory service interface
• The primary purpose of the directory service is to provide a
service for translating text names to UFIDs. In order to do so, it
maintains directory files containing the mappings between text
names for files and UFIDs.
• Each directory is stored as a conventional file with a UFID, so
the directory service is a client of the file service.
• For each operation, a UFID for the file containing the directory is
required .
Directory service operations

Lookup(Dir, Name) -> FileId Locates the text name in the directory and returns the
— throwsNotFound relevant UFID. If Name is not in the directory, throws an
exception.
AddName(Dir, Name, FileId) If Name is not in the directory, adds (Name, File) to the
— throwsNameDuplicate directory and updates the file’s attribute record.
If Name is already in the directory: throws an exception.
UnName(Dir, Name) If Name is in the directory: the entry containing Name is
— throwsNotFound removed from the directory.
If Name is not in the directory: throws an exception.
GetNames(Dir, Pattern) -> NameSeq
Returns all the text names in the directory that match the
regular expression Pattern.
Directory service operations
• lookup a file identifier(UFID) given a name and directory
• link a name to a file identifier in a directory
• remove a link
• list all names in a directory

The directory service does not create nor manipulate files.


Hierarchic file system

• A hierarchic file system such as the one that UNIX provides consists of
a number of directories arranged in a tree structure.
• A UNIX-like file-naming system can be implemented by the client
module using the flat file and directory services that we have defined.
• A tree-structured network of directories is constructed with files at the
leaves and directories at the other nodes of the tree.
• The root of the tree is a directory with a ‘well-known’ UFID.
• A function can be provided in the client module that gets the UFID of a
file given its pathname.
• The function interprets the pathname starting from the root, using
Lookup to obtain the UFID of each directory in the path.
File group

• A filegroup is a collection of files that can be located on any


server.
• File group identifiers must be unique throughout a distributed
system.
• whenever a new file group is created, a unique identifier can be
generated by concatenating the 32-bit IP address of the host
creating the new group with a 16-bit integer derived from the
date, producing a unique 48-bit integer:
Thank You

You might also like