IBM AS-400e User Manual

AS/400e

IBM

OS/400 Network File System Support

Ve r s i o n 4

SC41-5714-01

AS/400e

IBM

OS/400 Network File System Support

Ve r s i o n 4

SC41-5714-01

Note

Before using this information and the product it supports, be sure to read the information in “Notices” on page 99.

Second Edition (May 1999)

This edition replaces SC41-5714-00.

Note to U.S. Government Users — Documentation related to restricted rights — Use, duplication or disclosure is subject to restrictions set forth in GSA ADP Schedule Contract with IBM Corp.

Contents

Figures ........................... vii

Tables ........................... ix

About OS/400 Network File System Support (SC41-5714) ....... xi

Who should read this book .................... xi

AS/400 Operations Navigator ................... xi

Installing Operations Navigator.................. xii

Prerequisite and related information ................. xii

How to send your comments ...................xiii

Summary of Changes .....................xv

Chapter 1. What is the Network File System? ............ 1

Introduction.......................... 1

A Brief History ......................... 3

The Network File System as a File System .............. 3

Stateless Network Protocol .................... 4

Overview of the TULAB Scenario.................. 4

Chapter 2. The Network File System Client/Server Model........ 7

Network File System Client/Server Communication Design ........ 7

Network File System Process Layout ............... 8

Network File System Stack Description .............. 8

AS/400 as a Network File System Server ............... 9

Network File System Server-Side Daemons ............. 9

AS/400 as a Network File System Client ...............11

Network File System Client-Side Daemons .............12

NFS Client-Side Caches ....................12

Chapter 3. NFS and the User-Deﬁned File System (UDFS) .......15

User File System Management ..................15

Create a User-Deﬁned File System ................15

Display a User-Deﬁned File System ................17

Delete a User-Deﬁned File System ................18

Mount a User-Deﬁned File System ................19

Unmount a User-Deﬁned File System ...............20

Saving and Restoring a User-Deﬁned File System ..........21

Graphical User Interface ....................21

User-Deﬁned File System Functions in the Network File System ......22

Using User-Deﬁned File Systems with Auxiliary Storage Pools ......23

Chapter 4. Server Exporting of File Systems ............25

What is Exporting? .......................25

Why Should I Export? ......................26

TULAB Scenario .......................26

What File Systems Can I Export?..................27

How Do I Export File Systems? ..................28

Rules for Exporting File Systems .................28

CHGNFSEXP (Change Network File System Export) Command .....30

Exporting from Operations Navigator ...............33

Finding out what is exported ..................36

Exporting Considerations ....................38

Chapter 5. Client Mounting of File Systems .............39

What Is Mounting? .......................39

Why Should I Mount File Systems? .................41

What File Systems Can I Mount?..................42

Where Can I Mount File Systems? .................42

Mount Points ........................45

How Do I Mount File Systems? ..................45

ADDMFS (Add Mounted File System) Command ...........45

RMVMFS (Remove Mounted File System) Command .........48

DSPMFSINF (Display Mounted File System Information) Command ....50

Chapter 6. Using the Network File System with AS/400 File Systems ...55

″Root″ File System (/) ......................55

Network File System Differences .................56

Open Systems File System (QOpenSys) ...............56

Network File System Differences .................56

Library File System (QSYS.LIB) ..................57

Network File System Differences .................57

Document Library Services File System (QDLS) ............60

Network File System Differences .................60

Optical File System (QOPT)....................61

Network File System Differences .................61

User-Deﬁned File System (UDFS) .................62

Network File System Differences .................63

Administrators of UNIX Clients ...................63

Network File System Differences .................63

Chapter 7. NFS Startup, Shutdown, and Recovery ..........65

Conﬁguring TCP/IP .......................65

Implications of Improper Startup and Shutdown ............66

Proper Startup Scenario .....................66

STRNFSSVR (Start Network File System Server) Command.......67

Proper Shutdown Scenario ....................70

Shutdown Consideration ....................70

ENDNFSSVR (End Network File System Server) Command .......70

Starting or stopping NFS from Operations Navigator...........72

Locks and Recovery ......................74

Why Should I Lock a File? ...................74

How Do I Lock A File?.....................74

Stateless System Versus Stateful Operation .............74

RLSIFSLCK (Release Integrated File System Locks) Command .....75

Chapter 8. Integrated File System APIs and the Network File System ...77

Error Conditions ........................77

ESTALE Error Condition ....................77

EACCES Error Condition ....................77

API Considerations .......................77

User Datagram Protocol (UDP) Considerations............77

Client Timeout Solution ....................78

Network File System Differences ..................78

open(), create(), and mkdir() APIs ................79

fcntl() API .........................79

Unchanged APIs ........................79

Chapter 9. Network File System Security Considerations........81

The Trusted Community .....................81

iv OS/400 Network File System Support V4R4

Network Data Encryption ....................82

User Authorities ........................83

User Identiﬁcations (UIDs) ...................83

Group Identiﬁcations (GIDs)...................83

Mapping User Identiﬁcations ..................84

Proper UID Mapping .....................86

Securely Exporting File Systems ..................87

Export Options .......................88

Appendix A. Summary of Common Commands ...........91

Appendix B. Understanding the /etc Files..............93

Editing ﬁles within the /etc directory .................93

Editing stream ﬁles by using the Edit File (EDTF) command .......93

Editing stream ﬁles by using a PC based editor ...........94

Editing stream ﬁles by using a UNIX editor via NFS ..........94

/etc/exports File ........................94

Formatting Entries in the /etc/exports File..............94

Examples of Formatting /etc/exports with HOSTOPT Parameter .....96

/etc/netgroup File........................96

/etc/rpcbtab File ........................97

/etc/statd File .........................97

Notices ...........................99

Programming Interface Information .................101

Trademarks..........................101

Bibliography .........................103

Index ............................105

Readers’ Comments — We’d Like to Hear from You..........113

Contents v

vi OS/400 Network File System Support V4R4

Figures

1. AS/400 Operations Navigator Display ..............xii

2. The local client and its view of the remote server before exporting data . . 1

3. The local client and its view of the remote server after exporting data . . 2

4. The local client mounts data from a remote server ......... 2

5. Remote ﬁle systems function on the client............. 2

6. The TULAB network namespace ................ 5

7. The NFS Client/Server Model ................. 7

8. A breakdown of the NFS client/server protocol ........... 8

9. The NFS Server ......................10

10. The NFS Client ......................12

11. Using the Create User-Deﬁned FS (CRTUDFS) display........16

12. Display User-Deﬁned FS (DSPUDFS) output (1/2)..........17

13. Display User-Deﬁned FS (DSPUDFS) output (2/2)..........18

14. Using the Delete User-Deﬁned FS (DLTUDFS) display ........19

15. A Windows 95 view of using the CRTUDFS (Create UDFS) command . . 21

16. A Windows 95 view of using the DSPUDFS (Display UDFS) command . . 22

17. Exporting ﬁle systems with the /etc/exports ﬁle ...........25

18. Dynamically exporting ﬁle systems with the ″-I″ option ........26

19. Before the server has exported information ............27

20. After the server has exported /classes/class2 ...........28

21. A directory tree before exporting on TULAB2............29

22. The exported directory branch /classes on TULAB2 .........29

23. The exported directory branch /classes/class1 on TULAB2 ......29

24. Using the Change NFS Export (CHGNFSEXP) display ........31

25. The Operations Navigator interface. ...............34

26. The NFS Export dialog box. ..................34

27. The Add Host/Netgroup dialog box. ...............35

28. The Customize NFS Clients Access dialog box............36

29. The NFS Exports dialog box. .................37

30. A local client and remote server with exported ﬁle systems ......39

31. A local client mounting ﬁle systems from a remote server .......40

32. The mounted ﬁle systems cover local client directories ........40

33. The local client mounts over a high-level directory..........41

34. The local client mounts over the /2 directory ............41

35. Views of the local client and remote server ............43

36. The client mounts /classes/class1 from TULAB2 ..........43

37. The /classes/class1 directory covers /user/work...........43

38. The remote server exports /engdata ...............44

39. The local client mounts /engdata over a mount point .........44

40. The /engdata directory covers /user/work .............44

41. Using the Add Mounted FS (ADDMFS) display ...........46

42. A Windows 95 view of Mounting a user-deﬁned ﬁle system ......47

43. Using the Remove Mounted FS (RMVMFS) display .........49

44. Using the Display Mounted FS Information (DSPMFSINF) display ....51

45. Display Mounted FS Information (DSPMFSINF) output (1/2) ......52

46. Display Mounted FS Information (DSPMFSINF) output (2/2) ......52

47. The ″Root″ (/) ﬁle system accessed through the NFS Server ......55

48. The QOpenSys ﬁle system accessed through the NFS Server .....56

49. The QSYS.LIB ﬁle system accessed through the NFS Server .....57

50. The QDLS ﬁle system accessed through the NFS Server .......60

51. The QOPT ﬁle system accessed through the NFS Server .......61

52. The UDFS ﬁle system accessed through the NFS Server .......62

53. Using the Start NFS Server (STRNFSSVR) display .........69

54. Using the End NFS Server (ENDNFSSVR) display .........71

55. Starting or stopping NFS server daemons. ............73

56. NFS Properties dialog box. ..................73

57. Using the Release File System Locks (RLSIFSLCK) display ......76

58. Client outside the trusted community causing a security breaches ....82

viii OS/400 Network File System Support V4R4

Tables

1. CL Commands Used in Network File System Applications .......91

x OS/400 Network File System Support V4R4

About OS/400 Network File System Support (SC41-5714)

The purpose of this book is to explain what the Network File System is, what it does, and how it works on AS/400. The book shows real-world examples of how you can use NFS to create a secure, useful integrated ﬁle system network. The intended audiences for this book are:

v System administrators developing a distributed network using the Network File

System. v Users or programmers working with the Network File System

Chapters one and two introduce NFS by giving background and conceptual information on its protocol, components, and architecture. This is background information for users who understand how AS/400 works, but do not understand NFS.

The rest of the book (chapters three through nine) shows detailed examples of what NFS can do and how you can best use it. The overall discussion topic of this book is how to construct a secure, user-friendly distributed namespace. Included are in-depth examples and information regarding mounting, exporting, and the following topics:

v How NFS functions in the client/server relationship v NFS exceptions for AS/400 ﬁle systems v NFS startup, shutdown, and recovery v File locking v New integrated ﬁle system error conditions and how NFS affects them v Troubleshooting procedures for NFS security considerations

It is assumed that the reader has experience with AS/400 client/server model, though not necessarily with the Network File System.

Who should read this book

This book is for AS/400 users, programmers, and administrators who want to know about the Network File System on AS/400. This book contains:

v Background theory and concepts regarding NFS and how it functions v Examples of commands, AS/400 displays, and other operations you can use with

NFS v Techniques on how to construct a secure, efficient namespace with NFS

AS/400 Operations Navigator

AS/400 Operations Navigator is a powerful graphical interface for Windows clients. With AS/400 Operations Navigator, you can manage and administer your AS/400 systems from your Windows desktop.

You can use Operations Navigator to manage communications, printing, database, security, and other system operations. Operations Navigator includes Management Central for managing multiple AS/400 systems centrally.

Figure 1 on page xii shows an example of the Operations Navigator display:

Figure 1. AS/400 Operations Navigator Display

This new interface has been designed to make you more productive and is the only user interface to new, advanced features of OS/400. Therefore, IBM recommends that you use AS/400 Operations Navigator, which has online help to guide you. While this interface is being developed, you may still need to use a traditional emulator such as PC5250 to do some of your tasks.

Installing Operations Navigator

To use AS/400 Operations Navigator, you must have Client Access installed on your Windows PC. For help in connecting your Windows PC to your AS/400 system, consult

AS/400 Operations Navigator is a separately installable component of Client Access that contains many subcomponents. If you are installing for the ﬁrst time and you use the Typical installation option, the following options are installed by default:

v Operations Navigator base support v Basic operations (messages, printer output, and printers)

To select the subcomponents that you want to install, select the Custom installation option. (After Operations Navigator has been installed, you can add subcomponents by using Client Access Selective Setup.)

1. Display the list of currently installed subcomponents in the Component

2. Select AS/400 Operations Navigator.

3. Select any additional subcomponents that you want to install and continue with

Client Access Express for Windows - Setup

Selection window of Custom installation or Selective Setup.

Custom installation or Selective Setup.

, SC41-5507-00.

After you install Client Access, double-click the AS400 Operations Navigator icon on your desktop to access Operations Navigator and create an AS/400 connection.

Prerequisite and related information

Use the AS/400 Information Center as your starting point for looking up AS/400 technical information. You can access the Information Center from the AS/400e Information Center CD-ROM (English version: Web sites:

xii OS/400 Network File System Support V4R4

SK3T-2027

) or from one of these

http://www.as400.ibm.com/infocenter http://publib.boulder.ibm.com/pubs/html/as400/infocenter.htm

The AS/400 Information Center contains important topics such as logical partitioning, clustering, Java, TCP/IP, Web serving, and secured networks. It also contains Internet links to Web sites such as the AS/400 Online Library and the AS/400 Technical Studio. Included in the Information Center is a link that describes at a high level the differences in information between the Information Center and the Online Library.

For a list of related publications, see the “Bibliography” on page 103.

How to send your comments

Your feedback is important in helping to provide the most accurate and high-quality information. If you have any comments about this book or any other AS/400 documentation, ﬁll out the readers’ comment form at the back of this book.

v If you prefer to send comments by mail, use the readers’ comment form with the

address that is printed on the back. If you are mailing a readers’ comment form

from a country other than the United States, you can give the form to the local

IBM branch office or IBM representative for postage-paid mailing. v If you prefer to send comments by FAX, use either of the following numbers:

– United States and Canada: 1-800-937-3430

– Other countries: 1-507-253-5192 v If you prefer to send comments electronically, use one of these e-mail addresses:

– Comments on books:

RCHCLERK@us.ibm.com IBMMAIL, to IBMMAIL(USIB56RZ)

– Comments on the AS/400 Information Center:

RCHINFOC@us.ibm.com

Be sure to include the following:

v The name of the book. v The publication number of the book. v The page number or topic to which your comment applies.

About OS/400 Network File System Support (SC41-5714) xiii

xiv OS/400 Network File System Support V4R4

Summary of Changes

This manual includes changes made since Version 4 Release 1 of the OS/400 licensed program on the AS/400 system. This edition includes information that has been added to the system to support Version 4 Release 4.

Changes made to this book include the following items:

v Updated graphic ﬁles. v Updated examples. v Updated NFS to FSS/400 comparisons. v Added information about short and long names. v Added a new section about editing ﬁles within the /etc directory.

xvi OS/400 Network File System Support V4R4

Chapter 1. What is the Network File System?

Introduction

OS/400 Network File System Support

aids users and administrators who work with network applications and ﬁle systems. You can use the Network File System (NFS**) to construct a distributed network system where all users can access the data they need. Furthermore, the Network File System provides a method of transmitting data in a client/server relationship.

The Network File System makes remote objects stored in ﬁle systems appear to be local, as if they reside in the local host. With NFS, all the systems in a network can share a single set of ﬁles. This eliminates the need for duplicate ﬁle copies on every network system. Using NFS aids in the overall administration and management of users, systems, and data.

NFS gives users and administrators the ability to distribute data across a network by:

v Exporting local ﬁle systems from a local server for access by remote clients.

This allows centralized administration of ﬁle system information. Instead of

duplicating common directories on every system, NFS shares a single copy of a

directory with all the proper clients from a single server. v Mounting remote server ﬁle systems over local client directories. This allows

AS/400 client systems to work with ﬁle systems that have been exported from a

remote server. The mounted ﬁle systems will act and perform as if they exist on

the local system. The following ﬁgures show the process of a remote NFS server exporting

directories to a local client. Once the client is aware of the exported directories, the client then mounts the directories over local directories. The remote server directories will now function locally on the client.

introduces a system function for AS/400 that

Figure 2. The local client and its view of the remote server before exporting data

Before the server exports information, the client does not know about the existence of ﬁle systems on the server. Furthermore, the client does not know about any of the ﬁle systems or objects on the server.

Figure 3. The local client and its view of the remote server after exporting data

After the server exports information, the proper client (the client with the proper authorities) can be aware of the existence of ﬁle systems on the server. Furthermore, the client can mount the exported ﬁle systems or directories or objects from the server.

Figure 4. The local client mounts data from a remote server

The mount command makes a certain ﬁle system, directory, or object

accessible

the client. Mounting does not copy or move objects from the server to the client. Rather, it makes

Figure 5. Remote ﬁle systems function on the client

remote

When remote objects are mounted locally, they are placed over. Mounted objects also cover any objects that are

objects available for use

locally

cover up

any local objects that they

downstream

of the mount point, the place on the client where the mount to the server begins. The mounted objects will function locally on the client just as they do remotely on the server.

For more information on these aspects of NFS, see the following sections: v “Chapter 4. Server Exporting of File Systems” on page 25

v “Chapter 5. Client Mounting of File Systems” on page 39

2 OS/400 Network File System Support V4R4

| | | | | | |

A Brief History

OS/400 Network File System Support is the replacement for the TCP/IP File Server Support/400 (FSS/400) system application. Users who are accustomed to working with FSS/400 will notice many similarities between FSS/400 and NFS. It is important to note, however, that FSS/400 and NFS are other. The FSS/400 system application can exist on the same AS/400 with OS/400 Network File System Support, but they cannot operate together. On any given system, do not start or use FSS/400 and NFS at the same time.

Sun Microsystems, Inc.** released NFS in 1984. Sun introduced NFS Version 2 in

1985. In 1989, the Request For Comments (RFC) standard 1094, describing NFS Version 2, was published. X/Open published a compatible version that is a standard for NFS in 1992. Sun published the NFS Version 3 protocol in 1993.

Sun developed NFS in a UNIX** environment, and therefore many UNIX concepts (for example, the UNIX authentication) were integrated into the ﬁnal protocol. Yet the NFS protocol remains platform independent. Today, almost all UNIX platforms use NFS, as do many PCs, mainframes, and workstations.

not

compatible with each

| | |

Most implementations of NFS are Version 2, although a number of vendors are offering products that combine Version 2 and Version 3. The AS/400 implementation of the Network File System supports both Version 2 and Version 3 of the protocol.

The Network File System as a File System

AS/400 ﬁle systems provide the support that allows users and applications to access speciﬁc segments of storage. These logical units of′ storage are the following:

v libraries v directories v folders

The logical storage units can contain different types of data:

v objects v ﬁles v documents

Each ﬁle system has a set of logical structures and rules for interacting with information in storage. These structures and rules may be different from one ﬁle system to another, depending on the type of ﬁle system. The OS/400 support for accessing database ﬁles and various other object types through libraries can be thought of as a ﬁle system. Similarly, the OS/400 support for accessing documents through folders can be thought of as a separate ﬁle system. For more information on AS/400 ﬁle systems, please see the SC41-4711.

Integrated File System Introduction,

The Network File System provides seemingly “transparent” access to remote ﬁles. This means that local client ﬁles and ﬁles that are accessed from a remote server operate and function similarly and are indistinguishable. This takes away many complex steps from users, who need a set of ﬁles and directories that act in a consistent manner across many network clients. A long-term goal of system administrators is to design such a transparent network that solidiﬁes the belief of

Chapter 1. What is the Network File System? 3

users that all data exists and is processed on their local workstations. An efficient NFS network also gives the right people access to the right amount of data at the right times.

Files and directories can be made available to clients by exporting from the server and mounting on clients through a pervasive NFS client/server relationship. An NFS client can also, at the same time, function as an NFS server, just as an NFS server can function as a client.

Stateless Network Protocol

NFS incorporates the Remote Procedure Call (RPC) for client/server communication. RPC is a high-end network protocol that encompasses many simpler protocols, such as Transmission Control Protocol (TCP) and User Datagram Protocol (UDP).

NFS is a stateless protocol, maintaining absolutely no saved or archived information from client/server communications. State is the information regarding a request that describes exactly what the request does. A stateful protocol saves information about users and requests for use with many procedures. Statelessness is a condition where no information is retained about users and their requests. This condition demands that the information surrounding a request be sent with every single request. Due to NFS statelessness, each RPC request contains all the required information for the client and server to process user requests.

By using NFS, AS/400 users can bypass the details of the network interface. NFS isolates applications from the physical and logical elements of data communications and allows applications to use a variety of different transports.

In short, the NFS protocol is useful for applications that need to transfer information over a client/server network. For more information about RPC and NFS, see “Network File System Stack Description” on page 8.

Overview of the TULAB Scenario

This book uses the ﬁctional namespace TULAB to describe detailed applications of NFS concepts. A namespace is a distributed network space where one or more servers look up, manage, and share ordered, deliberate object names.

TULAB exists only in a hypothetical computer-networked environment at a ﬁctitious Technological University. It is run by a network administrator, a person who deﬁnes the network conﬁguration and other network-related information. This person controls how an enterprise or system uses its network resources. The TULAB administrator, Chris Admin, is trying to construct an efficient, transparent, and otherwise seamless distributed namespace for the diverse people who use the TULAB:

v Engineering undergraduate students v Humanities undergraduate students v Engineering graduate students v TULAB consultants

4 OS/400 Network File System Support V4R4

Each group of users works on sets of clients that need different ﬁle systems from the TULAB server. Each group of users has different permissions and authorities and will pose a challenge to establishing a safe, secure NFS namespace.

Chris Admin will encounter common problems that administrators of NFS namespaces face every day. Chris Admin will also work through some uncommon and unique NFS situations. As this book describes each command and parameter, Chris Admin will give a corresponding example from TULAB. As this book explains applications of NFS, Chris Admin will show exactly how he conﬁgures NFS for TULAB.

The network namespace of TULAB is complex and involves two NFS server systems:

1. TULAB1 — A UNIX server system

2. TULAB2 — An AS/400 server system The following ﬁgure describes the layout of the TULAB namespace.

Figure 6. The TULAB network namespace

Chapter 1. What is the Network File System? 5

6 OS/400 Network File System Support V4R4

Chapter 2. The Network File System Client/Server Model

To understand how the Network File System works on AS/400, you must ﬁrst understand the communication relationship between a server and various clients. The client/server model involves a local host (the client) that makes a procedure call that is usually processed on a different, remote network system (the server). To the client, the procedure appears to be a local one, even though another system processes the request. In some cases, however, a single computer can act as both an NFS client

and

an NFS server.

Figure 7. The NFS Client/Server Model

There are various resources on the server which are not available on the client, hence the need for such a communication relationship. The host owning the needed resource acts as a server that communicates to the host which initiates the original call for the resource, the client. In the case of NFS, this resource is usually a shared ﬁle system, a directory, or an object.

RPC is the mechanism for establishing such a client/server relationship within NFS. RPC bundles up the arguments intended for a procedure call into a packet of data called a network datagram. The NFS client creates an RPC session with an NFS server by connecting to the proper server for the job and transmitting the datagram to that server. The arguments are then unpacked and decoded on the server. The operation is processed by the server and a return message (should one exist) is sent back to the client. On the client, this reply is transformed into a return value for NFS. The user’s application is re-entered as if the process had taken place on a local level.

Network File System Client/Server Communication Design

The logical layout of the Network File System on the client and server involves numerous daemons, caches, and the NFS protocol breakdown. An overview of each type of process follows.

A daemon is a process that performs continuous or system-wide functions, such as network control. NFS uses many different types of daemons to complete user requests.

A cache is a type of high-speed buffer storage that contains frequently accessed instructions and data. Caches are used to reduce the access time for this information. Caching is the act of writing data to a cache.

For information about NFS server daemons, see “Network File System Server-Side Daemons” on page 9. For information about NFS client daemons, see “Network File System Client-Side Daemons” on page 12. For information about client-side caches, see “NFS Client-Side Caches” on page 12 Detailed information about the NFS protocol can be found in “Network File System Stack Description”.

Network File System Process Layout

Figure 8. A breakdown of the NFS client/server protocol

Local processes that are known as daemons are required on both the client and the server. These daemons process both local and remote requests and handle client/server communication. Both the NFS client and server have a set of daemons that carry out user tasks. In addition, the NFS client also has data caches that store speciﬁc types of data locally on the on the client. For more information about the NFS client data caches, see “NFS Client-Side Caches” on page 12.

Network File System Stack Description

Simple low-end protocols make up a high-end complex protocol like NFS. For an NFS client command to connect with the server, it must ﬁrst use the Remote Procedure Call (RPC) protocol. The request is encoded into External Data

8 OS/400 Network File System Support V4R4

Representation (XDR) and then sent to the server using a socket. The simple User Datagram Packet (UDP) protocol actually communicates between client and server. Some aspects of NFS use the Transmission Control Protocol (TCP) as the base communication protocol.

The operation of NFS can be seen as a logical client-to-server communications system that speciﬁcally supports network applications. The typical NFS ﬂow includes the following steps:

1. The server waits for requests from one or more clients.

2. The client sends a request to the server and blocks (waits for a response).

3. When a request arrives, the server calls a dispatch routine.

4. The dispatch routine performs the requested service and returns with the results of the request. The dispatch routine can also call a sub-routine to handle the speciﬁc request. Sometimes the sub-routine will return results to the client by itself, and other times it will report back to the dispatch routine.

5. The server sends those results back to the client.

6. The client then de-blocks.

The overhead of running more than one request at the same time is too heavy for an NFS server, so it is designed to be server can only process one request per session. The requests from the multiple clients that use the NFS server are put into a queue and processed in the order in which they were received. To improve throughput, multiple NFS servers can process requests from the same queue.

single-threaded

. This means that an NFS

AS/400 as a Network File System Server

The NFS server is composed of many separate entities that work together to process remote calls and local requests. These are:

v NFS server daemons. These daemons handle access requests for local ﬁles

from remote clients. Multiple instances of particular daemons can operate simultaneously.

v Export command. This command allows a user to make local directories

accessible to remote clients.

v /etc/exports ﬁle. This ﬁle contains the local directory names that the NFS server

exports automatically when starting up. The administrator creates and maintains this ﬁle, which is read by the export command. For more discussion about this ﬁle, see “/etc/exports File” on page 94 and “Chapter 4. Server Exporting of File Systems” on page 25.

v Export table. This table contains all the ﬁle systems that are currently exported

from the server. The export command builds the /etc/exports ﬁle into the export table. Users can dynamically update the export table with the export command.

For discussion regarding the CHGNFSEXP (Change Network File System Export) and EXPORTFS (Export File System) commands and how they work with both the /etc/exports ﬁle, see “Chapter 4. Server Exporting of File Systems” on page 25.

Network File System Server-Side Daemons

Chapter 2. The Network File System Client/Server Model 9

Figure 9. The NFS Server

NFS is similar to other RPC-based services in its use of server-side daemons to process incoming requests. NFS may also use multiple copies of some daemons to improve overall performance and efficiency.

RPC Binder Daemon (RPCD)

| | | | |

This daemon is analogous to the port mapper daemon, which many implementations of NFS use in UNIX. Clients determine the port of a speciﬁed RPC service by using the RPC Binder Daemon. Local services register themselves with the local RPC binder daemon (port mapper) when initializing. On AS/400, you can register your own RPC programs with the RPC binder daemon.

NFS Server Daemons (NFSD)

The most pressing need for NFS server daemons centers around the need for multi-threading NFS RPC requests. Running daemons in user-level processes allows the server to have multiple, independent threads of processes. In this way, the server can handle several NFS requests at once. As a daemon completes the processing of a request, the daemon returns to the end of a line of daemons that wait for new requests. Using this schedule design, a server always has the ability to accept new requests if at least one server daemon is waiting in the queue. Multiple instances of this daemon can perform tasks simultaneously.

Mount Daemon (MNTD)

Each NFS server system runs a mount daemon which listens to requests from client systems. This daemon acts on mount and unmount requests from clients. If the mount daemon receives a client mount request, then the daemon checks the export table. The mount daemon compares it with the mount request to see if the client is allowed to perform the mount. If the mount is allowed, the mount daemon will send to the requesting client an opaque data structure, the ﬁle handle. This structure uniquely describes the mounting point that is requested by the client. This will enable the client to represent the root of the mounted ﬁle system when making future requests.

10 OS/400 Network File System Support V4R4

Network Status Monitor Daemon (NSMD)

The Network Status Monitor (NSM) is a stateful NFS service that provides applications with information about the status of network hosts. The Network Lock Manager (NLM) daemon heavily uses the NSM to track hosts that have established locks as well as hosts that maintain such locks.

There is a single NSM server per host. It keeps track of the state of clients and notiﬁes any interested party when this state changes (usually after recovery from a crash).

The NSM daemon keeps a informed after a state change. After a local change of state, the NSM notiﬁes each host in the notify list of the new state of the local NSM. When the NSM receives a state change notiﬁcation from another host, it will notify the local network lock manager daemon of the state change.

notify list

Network Lock Manager Daemon (NLMD)

The Network Lock Manager (NLM) daemon is a stateful service that provides advisory byte-range locking for NFS ﬁles. The NLM maintains state across requests, and makes use of the Network Status Monitor daemon (NSM) which maintains state across crashes (using stable storage).

The NLM supports two types of byte-range locks:

1. Monitored locks. These are reliable and helpful in the event of system failure. When an NLM server crashes and recovers, all the locks it had maintained will be reinstated without client intervention. Likewise, NLM servers will release all old locks when a client crashes and recovers. A Network Status Manager (NSM) must be functioning on both the client and the server to create monitored locks.

2. Unmonitored locks. These locks require explicit action to be released after a crash and re-established after startup. This is an alternative to monitoring locks, which requires the NSM on both the client and the server systems.

AS/400 as a Network File System Client

that contains information on hosts to be

Several entities work together to communicate with the server and local jobs on the NFS client. These processes are the following:

| | |

| | | |

v RPC Binder Daemon. This daemon communicates with the local and remote

daemons by using the RPC protocol. Clients look for NFS services through this daemon.

v Network Status Monitor and Network Lock Manager. These two daemons are

not mandatory on the client. Many client applications, however, establish byte-range locks on parts of remote ﬁles on behalf of the client without notifying the user. For this reason, it is recommended that the NSM and NLM daemons exist on both the NFS client and server.

v Block I/O daemon. This daemon manages the data caches and is therefore

stateful in operation. It performs caching, and assists in routing client-side NFS requests to the remote NFS server. Multiple instances of this daemon can perform tasks simultaneously.

v Data and attribute caches. These two caches enhance NFS performance by

storing information on the client-side to prevent a client/server interaction. The attribute cache stores ﬁle and directory attribute information locally on the client, while the data cache stores frequently used data on the client.

Chapter 2. The Network File System Client/Server Model 11

v Mount and Unmount commands. Users can mount and unmount a ﬁle system

in the client namespace with these commands. These are general tools, used not only in NFS, but also to dynamically mount and unmount other local ﬁle systems. For more information about the ADDMFS (Add Mounted File System) and RMVMFS (Remove Mounted File System) commands, see “Chapter 5. Client Mounting of File Systems” on page 39.

Network File System Client-Side Daemons

Figure 10. The NFS Client

Besides the RPC Daemon, the NFS client has only one daemon to process requests and to transfer data from and to the remote server, the block I/O daemon. NFS differs from typical client/server models in that processes on NFS clients make some RPC calls themselves, independently of the client block I/O daemon. An NFS client can optionally use both a Network Lock Manager (NLM) and a Network Status Monitor (NSM) locally, but these daemons are not required for standard operation. It is recommended that you use both the NLM and NSM on your client because user applications often establish byte-range locks without the knowledge of the user.

Block I/O Daemon (BIOD)

| | | | | | | |

The block I/O daemon handles requests from the client for remote ﬁles or operations on the server. The block I/O daemon may handle data requests from the client to remote ﬁles on the server. Running only on NFS clients or servers that are also clients, this daemon manages the data caches for the user. The block I/O daemon is stateful and routes client application requests either to the caches or on to the NFS server. The user can specify the regular intervals for updating all data that is cached by the block I/O daemon. Users can start multiple daemons to perform different operations simultaneously.

NFS Client-Side Caches

Caching ﬁle data or attributes gives administrators a way of tuning NFS performance. The caching of information allows you to delay writes or to read ahead.

12 OS/400 Network File System Support V4R4

+ 105 hidden pages

IBM AS-400e User Manual

Specifications and Main Features

Frequently Asked Questions

User Manual