File Service Architecture in Distributed System
A file system is a system where data is stored persistently. In this article, we will see the concept of File service architecture in distributed systems. The access control mechanism is used for sharing of data between multiple users. Furthermore, concurrent access is provided certainly for read-only access.
The following modules are the part of the file system:
- Directory module: This module gives the relation to file names by connecting them to their corresponding file IDs.
- File module: This module serves the purpose of relating file IDs to specific files.
- Access control module: This module provides the controlling feature by validating the requested operation.
- File access module: This module refers to the reading and writing of file data or attributes.
- Block module: This module accesses and allocates the disk block.
- Device module: This module refers to the disk I/O and buffering.
File Service Requirements:
Following are the requirements of file services:
- Transparency: File namespace is the same even after the relocation of files or processes. There is the possibility that files are automatically relocated. Performance is up to the mark for a given system load. The scaling can also be done to fulfill the additional loads.
- Concurrency: It must hold the property of isolation. Locking can be carried out at file-level or record-level keeping.
- Heterogeneous: The accessing of service by the client must be independent of the operating system or hardware platform. In other words, there should be design compatibility of file systems of different Operating systems.
- Replication: The replication file service maintains multiple identical copies of files.
- Consistency: There is a facility of one-copy update in Unix for file system operations on local files. Here, transparency is seen in caching mechanism.
- Security: There should be proper implementation regarding access control and privacy for local files. Secure communication must be followed for maintaining privacy. The authentication procedure should opt for remote users. Moreover, vulnerability is associated with impersonation and other similar attacks due to the opening of service interfaces to all processes.
- Fault tolerance: The executing service must have the ability to execute even client makes errors or crashes. Even after crashing the machine on the server-side, the service must be able to resume. The service can continue to operate even during a crash if there is a replication of the service.
- Efficiency: Distributed file system aims to achieve a performance level comparable to a local file system.
File Service Architecture:
File Service Architecture is an architecture that provides the facility of file accessing by designing the file service as the following three components:
- A client module
- A flat file service
- A directory service
The implementation of exported interfaces by the client module is carried out by flat-file and directory services on the server-side.
Let’s discuss the functions of these components in file service architecture in detail.
1. Flat file service: A flat file service is used to perform operations on the contents of a file. The Unique File Identifiers (UFIDs) are associated with each file in this service. For that long sequence of bits is used to uniquely identify each file among all of the available files in the distributed system. When a request is received by the Flat file service for the creation of a new file then it generates a new UFID and returns it to the requester.
Flat File Service Model Operations:
- Read(FileId, i, n) -> Data: Reads up to n items from a file starting at item ‘i’ and returns it in Data.
- Write(FileId, i, Data): Write a sequence of Data to a file, starting at item I and extending the file if necessary.
- Create() -> FileId: Creates a new file with length 0 and assigns it a UFID.
- Delete(FileId): The file is removed from the file store.
- GetAttributes(FileId) -> Attr: Returns the file’s file characteristics.
- SetAttributes(FileId, Attr): Sets the attributes of the file.
2. Directory Service: The directory service serves the purpose of relating file text names with their UFIDs (Unique File Identifiers). The fetching of UFID can be made by providing the text name of the file to the directory service by the client. The directory service provides operations for creating directories and adding new files to existing directories.
Directory Service Model Operations:
- Lookup(Dir, Name) -> FileId : Returns the relevant UFID after finding the text name in the directory. Throws an exception if Name is not found in the directory.
- AddName(Dir, Name, File): Adds(Name, File) to the directory and modifies the file’s attribute record if Name is not in the directory. If a name already exists in the directory, an exception is thrown.
- UnName(Dir, Name): If Name is in the directory, the directory entry containing Name is removed. An exception is thrown if the Name is not found in the directory.
- GetNames(Dir, Pattern) -> NameSeq: Returns all the text names that match the regular expression Pattern in the directory.
3. Client Module: The client module executes on each computer and delivers an integrated service (flat file and directory services) to application programs with the help of a single API. It stores information about the network locations of flat files and directory server processes. Here, recently used file blocks hold in a cache at the client-side, thus, resulting in improved performance.