A Basic Distributed File System

Client-side file system

We now will study the architecture of a simplified distributed file system. A simple client/server distributed file system has more components than the file systems we have studied so far. On the client side, there are client applications that access files and directories through the client-side file system. A client application issues system calls to the client-side file system (such as open(), read(), write(), close(), mkdir(), etc.) in order to access files which are stored on the server. Thus, to client applications, the file system does not appear to be any different than a local (disk-based) file system, except perhaps for performance. In this way, distributed file systems provide transparent access to files, an obvious goal. After all, who would want to use a file system that required a different set of APIs or otherwise was a pain to use?

File server

The role of the client-side file system is to execute the actions needed to service those system calls. For example, if the client issues a read() request, the client-side file system may send a message to the server-side file system (or, as it is commonly called, the file server) to read a particular block. The file server will then read the block from disk (or its own in-memory cache), and send a message back to the client with the requested data. The client-side file system will then copy the data into the user buffer supplied to the read() system call and thus the request will complete. Note that a subsequent read() of the same block on the client may be cached in client memory or on the client’s disk even; in the best such case, no network traffic need be generated.