Anh Phan Nguyen anguyen139@student.gsu.edu CSC-8320 Advanced Operating System chapter 11.4 Naming in Distributed File System Anh Phan Nguyen anguyen139@student.gsu.edu

Agenda Introduction to NFS naming system Problems with design of NFS naming system: name resolve and mounting. File handler Automounting AFS vs NFS Conclusion

Introduction blocks are where file/directories actually saved on disk index node (inode) contains information on where the data is saved on disk (blocks)

introduction

Introduction-mounting mounted file system is letting directory node store identifier of different directory node from another namesapce. vu is mount point, /home/steen is mounting point user access /remote/vu on its own machine. The NFS url is used to locate content from remote.

Introduction NFS is a client-server based network file system. Support small work group with small number of clients and servers.

Naming in NFS Provide transparent: remote directory is treated same as local one. Remote directories can be mounted as local file. Part of a file system could be exported.

Mounting in NFS user type ls /remote/vu to access remote content. There is no need to remember the link or know about protocol. mbox is part of system B, export to system A

Problem with transparent mounting point Different user has different names for mounted folder. User A may have named /remote/vu/mbox for the remote folder in server C. User B may have named /work/me/mbox for the remote folder in server C.

Problem with transparent mounting point Solution: partly standardize the namespace. Example: use /usr/bin to mount remote file system. Use /local/ to mount local host. Previous problem: both A and B stores mbox folder on /usr/bin, so that both A and B can communicate the file path to each other.

NSF server and mounting NFS server can mount directories from other NFS server. NFS server cannot export directories it does not own. The reason is for simplicity.

A mount install from B into draw. A export draw, which contains install. Client then mount install into draw folder. However, client can only see draw, but not install. This is by design for simplicity

NSF server and mounting There are two type of name resolution in NSF. Strictly iterative for NFSv3 Recursively request for NFSv4. For example: /bin/draw/install requires three consecutive calls for NFSv3 and one for NSFv4. In NFSv3, client will not see install. In NFSv4, client will receive handle of the mounted directory install. Client know if it cross a mount point.

File handle A reference to a file. It is implemented as a true identifier for a given file system. File handle is unique inside file system hosted by server. Server don not have to have multiple name lookup, which improve performance. Client can access the file independently of its name. Server must not reuse file handler of deleted file.

Auto mounting Alice wants to mount /home/alice from remote server to her local workstation every time she logs in. Alice also wants to access public file shared by bob under named /home/bobs. Should this directory be mounted overtime Alice log in? Pros: mounting service is transparent to Alice. Cons: lots of auto mounting pose scalable problem, since there would be lots of network at the same time.

Auto mounting Solution: mounting on demand for unimportant folder Automounter is a process separate from NSF client.

Every time Alice login, login program sent lookup request /home/alice. The request is forward to NFS client, which intern forward to automounter. Automounter creates alice folder locally, then lookup server which export alice folder. Automounter finally mount the remote folder to local folder alice.

Atomounting Another approach is folder created by automounting is named differently. A symbolic link is then created. NFS use symbolic link to communicated directly with remote server. This allow automounter not to involve too much in the naming process.

NFS vs AFS NFS is a typical and popular distributed file system. + Use client-server approach which limits its scalability. + Simple, not secure, not reliable. AFS provide much larger scale with thousands of machines. + Secure, provide authentication & encryption service. + Allow version controls. + Scalable.

Current state of the art For really large data sets, scalable and flexible demand, use Hadoop file system. Hadoop is a true distributed system which support replication for both reliability and performance.

Current state of the art Hadoop only support Map-reduced with batch processing. For effectively query data from Hadoop, Sparks is used as an compliment. Sparks is install on top of Hadoop, provide users with an interactive framework for analysis and querying.

Conclusion. Two main point of NFS are mounting service and name resolve service. NFS are simple & not scalable service. For larger scale, use AFS.

References [1] Andrew S. Tanenbaum, Maarten Van Steen Distributed Systems Principles and Paradigms 2nd Edition. 2006 [2] http://www.cs.cmu.edu/~410- s05/lectures/L30_NFSAFS.pdf [3] Konstantin Shvachko et. al. The Hadoop Distributed File System. Mass Storage Systems and Technologies (MSST), 2010 IEEE 26th Symposium. [4] Matei Zaharia et. al. Apache Spark: a unified engine for big data processing. Communications of the ACM. Volume 59 Issue 11, November 2016