--- title: "Need of naming; Sun NFS" subject: "Distributed System" chapter: 2 key: "semester_7/distributed_system:naming-nfs" source: https://www.bctengineer.com/q/semester_7/distributed_system/naming-nfs site: BCT Engineering --- # Need of naming; Sun NFS Distributed System · Chapter 2: Distributed Objects and File System - Asked in: 2075 Asoj, 2+6 marks - Video: [CS 407 Distributed Computing - Module 4 - SUN NFS](https://www.youtube.com/watch?v=DAZWz04o7RI) — Dept. of Computer Science & Engineering, CCE - Answer checked by Claude Opus 5.5 (high effort) on 2026-10-14 - Page: https://www.bctengineer.com/q/semester_7/distributed_system/naming-nfs - Whole chapter: https://www.bctengineer.com/md/semester_7/distributed_system/chapter-2 ## Question Why is naming necessary in distributed system? Explain Sun Network File System architecture with its features. ## Short answer Naming provides location independence, sharing, and resolution of resources. SUN NFS features a VFS layer, NFS client/server using RPC, file handles, mount service, and stateless operation with caching for access transparency. ## Answer #### Need of naming A **name** identifies a resource (file, host, service, user). Naming is necessary because: - Users and programs refer to resources by names, not by addresses or identifiers. - Names are location independent, so a resource can move or be replicated without clients changing. - Names allow sharing of resources among users (the same name gives the same resource). - A name service finds the attributes (address) of a named resource (name resolution), for example DNS. - It gives uniqueness, grouping (directories) and access control on resources. #### Sun NFS **SUN NFS** (Network File System) is the most widely used distributed file service, developed by Sun Microsystems. It lets a client access remote files as if they were local, over an RPC-based protocol that is independent of the operating system, hardware and network. **Architecture** ```text Client computer Server computer +-----------------------------+ +-----------------------------+ | Application programs | | | |-------- UNIX kernel --------| |-------- UNIX kernel --------| | Virtual file system | | Virtual file system | | | | | | | | | | +----v-----+ +-----v-----+ | | +-----v-----+ +-----v----+ | | | UNIX | | NFS | | | | NFS | | UNIX | | | | file | | client | | | | server | | file | | | | system | | | | | | | | system | | | +----------+ +-----+-----+ | | +-----+-----+ +----------+ | +---------------------|-------+ +-------|---------------------+ | | +<---- NFS protocol --->+ (RPC over UDP/TCP) ``` - **Virtual file system (VFS):** a layer in the kernel that decides whether a request is for a local file or a remote file and passes it to the UNIX file system or to the NFS client. It keeps a *v-node* for each open file; the v-node holds an i-node reference for a local file or a *file handle* for a remote file. - **NFS client:** translates VFS operations into RPC requests to the server. - **NFS server:** receives requests, identifies the file by its **file handle** (file system id, i-node number, i-node generation number), and calls the local file system. - **Mount service:** a client mounts a remote directory into its local file tree. The server lists the file systems it exports in /etc/exports, and the client records each mounted remote directory in its mount table. - **Automounter:** mounts a remote directory on first use. **Operation** 1. The application issues a system call (for example read). 2. The VFS finds that the file is remote and calls the NFS client. 3. The NFS client sends an RPC (lookup, read, write, getattr, create, remove, mkdir, readdir...) over UDP/TCP using XDR encoding. 4. The NFS server's VFS finds the local file by the file handle, runs the operation on the local file system and returns the result. 5. The client caches the data (block cache) and attributes. Cache validity is checked by comparing timestamps; a cached entry is trusted for a freshness interval of about 3–30 seconds for files and 30–60 seconds for directories. **Features / properties** - **Access and location transparency** through mounting. - **Stateless server:** each request carries all the information needed, so a crashed server restarts without recovery work; operations are idempotent. - **Heterogeneity:** works with any OS that implements the protocol. - **Caching:** read-ahead and delayed write for performance, with approximate (not strict one-copy) consistency. - **Security:** the original version trusted the user id sent in the RPC; later versions use Kerberos. - **Limited replication and migration support.** ## Check yourself The answer's key points as multiple-choice questions, with the correct option and why. 1. How does naming help when a resource moves or is replicated? A. Names are location independent, so clients need not change B. Clients must update the address by hand C. Names must be changed when the resource moves D. Names are tied to the physical address Answer: A. Location-independent names enable movement and replication. (Key point: Location independence) 2. What does a name service do? A. Stores file data B. Encrypts requests C. Finds the attributes (such as address) of a named resource D. Schedules processes Answer: C. DNS is an example of name resolution. (Key point: Name resolution) 3. What does the Virtual File System (VFS) layer do in NFS? A. Decides whether a request is for a local or a remote file and passes it to the UNIX file system or the NFS client B. Stores the file data of remote clients on the server C. Encrypts all RPC messages between client and server D. Mounts remote directories automatically on first use Answer: A. The VFS sits in the kernel and routes each request, using v-nodes for local and file handles for remote files. (Key point: Role of VFS) 4. Why can a crashed NFS server simply restart without recovery work? A. It keeps a log of every client's open files on disk B. It is stateless: each request carries all needed information and operations are idempotent C. Clients must re-open all files after the restart D. It uses callbacks to tell clients what to resend Answer: B. Because no client state is held, there is nothing to rebuild; repeated requests are harmless. (Key point: Stateless server) ## Related in Distributed System - [SUN NFS architecture and operation](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Asun-nfs-architecture) — Distributed System, chapter 2, asked 3× - [Stateful vs stateless; NFS architecture](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Anfs-stateful-stateless) — Distributed System, chapter 2 - [Stub, skeleton and NFS architecture](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Astub-skeleton-nfs) — Distributed System, chapter 2 - [DFS requirements and file service architecture](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Adfs-requirements-architecture) — Distributed System, chapter 2 - [Context switching; distributed vs network OS](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Acontext-switch-dos) — Distributed System, chapter 3 - [Network OS vs distributed OS](https://www.bctengineer.com/question.md?key=semester_7%2Fdistributed_system%3Anos-vs-dos-diff) — Distributed System, chapter 3 ## Related in other subjects - [Google File System architecture](https://www.bctengineer.com/question.md?key=semester_8%2Fbig_data_technologies%3Agfs-architecture) — Big Data Technologies, chapter 2, asked 2× - [Distributed object versus multiprocessor architecture](https://www.bctengineer.com/question.md?key=semester_5%2Fsoftware_engineering%3Adistributed-object-vs-multiprocessor) — Software Engineering, chapter 3 - [Client-server versus distributed object architecture](https://www.bctengineer.com/question.md?key=semester_5%2Fsoftware_engineering%3Aclient-server-vs-distributed-object) — Software Engineering, chapter 3 - [Features of client/server architecture](https://www.bctengineer.com/question.md?key=semester_7%2Fcomputer_networks_and_security%3Aclient-server-features) — Computer Networks and Security, chapter 1