![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to netb.ms CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [Research Unix] / researchv10dc / vol2 / netb|
Return to netb.ms CVS log | Up to [Research Unix] / researchv10dc / vol2 / netb |
1.1 root 1: .so ../ADM/mac
2: .XX netb 513 "A Look at the Ninth Edition Network File System"
3: .nr dP 2
4: .nr dV 3p
5: .nr tP 1
6: .nr tV 1p
7: .nr Hs 5
8: .TL M10200 40125-100
9: A Look at the Ninth Edition Network File System
10: .AU sar SF XT9112200 x6084 5-121 attunix!sar
11: Stephen Rago
12: .AI
13: .MH
14: .AB
15: The protocol used for the network file system in Research
16: .UX
17: has evolved since its original design and implementation. This paper describes the
18: current version of the protocol (NETB), including the semantics for both the client
19: and the server.
20: .AE
21: .2C
22: .NH 1
23: Introduction
24: .PP
25: In Version 8 of the
26: .UX
27: operating system, Peter Weinberger*
28: .FS
29: .nf
30: *
31: .ps 6
32: .ft H
33: .tr x.
34: .tr -
35: .cs H 5
36: .vs 8u
37: -------------------xxxxxx-x---------------------
38: -----------------xxxxxxxxxxxxx------------------
39: ----------------xxxxxxx-xxxxxxxx----------------
40: ---------------xx-xxxxxxx-xxxxxxxx--------------
41: ---------------xxxx-xxxxxxxxx-x-xxx-------------
42: --------------x---------xxxxxxxxxxxxx-----------
43: --------------x----------xxxxxxxxxxxxxxxx-------
44: ---------------------------xxxxx-xxxxxx---------
45: ------------xx-------------xxxxxxxxxxxxxxx------
46: ---------------------------x-x-xxxxxxxxxxx------
47: ----------xx---------------xxxxxxxxxxxxxxxxx----
48: ---------xxx----------------xxxxxxxxxxx-x-xx----
49: --------xx-------------------xxxxxxxxxxxxxxxx---
50: --------xxx------------------xxxxxxxxxxxxxx-x---
51: -------xxxx-------------------xxxxxxxxxxxxxxx---
52: ------xxxx---------------------xxxxxxxxxxxxxx---
53: ------xxxxx--------------------xxxxxxxxxxxxxx---
54: -----xxxxx----x-x---------------xxxxxxxxxxxx----
55: ----xxxxxxxxx-x-xxxxx-----xxxxxxx-xxxxxxxxxxx---
56: ----xxxxxxx------xxxxx---xx--xxxxxxxxxxxxxxxx---
57: ---xxxxxxxxx---xxxx-xxxxxxxxx--x-xxxxxxxxxxxx---
58: ---xxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx---
59: ---xxxxxxxxx-x-xx-x--x--xxxxxxxxxxxxxxxxxxxxx---
60: ---xxxxxxx-x------x--x---xxxxxxxxxxxxxxxxxxx----
61: ----xxxxxxx-----x--------x---x-xxxxxxxxxxxxx----
62: ---xxxxxx-x---------x----xxx------xxxxxxxxxx----
63: ------xx--x--------------xx-----xx-xxxxxxxx-----
64: ----x-xxx----------x------xx-------xxxxxx-------
65: -------xx------x-xx--------xxxxxxxxx-xxxx-------
66: --------x----x-x-x-------x-xx-x--x-xxxxx--------
67: --------------------x-xxxxxxx-xxxxxxxxxx--------
68: -------xx----------xxxxxxxx-x---xxx-xxx---------
69: ------xxx------------xxxxxxx--x-x-xxxxx---------
70: -------xx-----x-------xxxx-x-x-xxxx-xxxxxx------
71: --------x----------------xxx-x-x-xxxxxxxx-------
72: -------xxx-----xxx-x-x-xxx-xxx-x-x--xxxxx-------
73: --------xx-----x-x-x-xxxxxxxxxxxxxxxxxxxx-------
74: ---------x----------------xxx--x-xxxxxxx--------
75: ---------xx--------------xx-x-xxxx--xxx---------
76: -------------x-----xxxxxxxx-x-xx-xx-------------
77: ---------------------xxxxxxxxxxxxxxxx-----------
78: --------------x------------x-x-xx-x-------------
79: -------------------------x-x-xxxxx--------------
80: --------------x-----------xxxxxx-x--------------
81: ----------------x--------x--x-xxxx--------------
82: --------------x-x-xxx-xxxxxxxxx-x---------------
83: ----------------x---xxxxxxxxx-xxxx--------------
84: ---------------x-xxxx-x-x-xxxxxxxx--------------
85: .tr --
86: .tr xx
87: .fi
88: .vs
89: .ps
90: .ft
91: .FE
92: wrote a network file system that enabled files to be shared between machines
93: connected by a network. When I asked someone if there was a paper describing
94: it, they said, "yeah, but it's only an abstract." I thought they were speaking
95: figuratively. They were speaking literally |reference(weinberger neta).
96: Hence, as I began studying the
97: Version 9 network file system in preparation for porting it to UNIX System V Release 4.0,
98: it was suggested that I also document what it does.
99: This paper describes the inner workings of Weinberger's network file system.
100: .PP
101: The UNIX Version 8 network file system, known as NETA, provided remote file access
102: for the Computing Science Research Center. It has evolved over the years and
103: in its current form, runs on UNIX Version 9 and is now called NETB.
104: .NH 1
105: Architecture
106: .PP
107: The client side is implemented in the kernel as a file system switch entry. The server
108: side is implemented as a user-level process. There is one server process
109: per client machine.
110: .PP
111: The server's name is
112: .I zarf .
113: (A zarf is an ornamental metal holder for a hot coffee cup.)
114: .PP
115: By convention, each machine
116: mounts other machines' file systems on mount points under
117: .CW /n .
118: .NH 1
119: Client Startup
120: .PP
121: The client side of the network file system includes a command/daemon (\fIsetup\fP)
122: to set up
123: connections and a file system (NETB) to translate file system operations into
124: streams messages. \fISetup\fP makes a connection to the remote machine's server and
125: sends it information about the protocol version, client user ids, and client group ids.
126: Then it mounts the connection in the file system name space using NETB.
127: .PP
128: In the daemon mode, the command is started without any arguments. It reads the
129: file
130: .CW /usr/netb/friends
131: to decide which systems to mount.
132: Every 60 seconds the daemon checks the remotely mounted file systems to see if they are
133: still available. It also checks to see if the friends file has changed. If any friendly file
134: system is unavailable, then an attempt is made to mount it.
135: The format of the friends file is a list of entries containing a \fInetname\fP,
136: a \fIcall_arg\fP, a \fImount_point\fP,
137: a \fIprotocol\fP, a \fIunique_id\fP, a \fIdebug_flag\fP, and a \fIusername\fP,
138: separated by white space.
139: .PP
140: The \fInetname\fP is the network name (see
141: .I ipc (3))
142: of the server machine.
143: The \fImount_point\fP is the location in the local file system where the remote file
144: system is to be mounted.
145: The \fIprotocol\fP indicates how the connection is to be placed. Protocol
146: .CW d
147: uses the
148: default network
149: .CW dk
150: (Datakit\(rg), expecting the service to be named
151: .CW fsb
152: and ignoring the
153: \fIcall_arg\fP. Protocol
154: .CW t
155: uses TCP, starting the service given by the
156: \fIcall_arg\fP using the
157: .I rsh
158: protocol.
159: The \fIunique_id\fP is an integer between 0 and 255 that distinguishes the connections
160: and must be unique among all active remote file systems.
161: The \fIdebug_flag\fP determines how much information gets written to the log files.
162: The \fIusername\fP is an optional field that provides the name of the calling process
163: making the mount. The default user name is
164: .CW daemon .
165: .PP
166: In command mode, the remote file system is mounted, but no daemon is created.
167: The arguments to the command are the same as the parameters in the friends file.
168: .NH 1
169: Server Startup
170: .PP
171: The server expects to be started by the remote execution facility.
172: As such, file descriptor zero is attached to the network connection.
173: First, the server tries to identify the client. The method it uses depends
174: on the environment in which it is running.
175: On 4BSD systems, it does this by calling
176: .I getpeername (2).
177: On Version 9 (and System V)
178: systems, it does this
179: by checking the environment variables
180: .CW CSOURCE
181: and
182: .CW DKSOURCE .*
183: .FS
184: * CSOURCE is set by the remote execution facility when a service is invoked.
185: DKSOURCE is set by an older version of the remote execution facility.
186: .FE
187: The server then changes directory to
188: .CW /usr/netb .
189: If this fails, the server
190: changes directory to
191: .CW /tmp .
192: A log file,
193: .CW zarf.log ,
194: is created.
195: .PP
196: The first network message read by the server is 16 bytes long.
197: The format is:
198: .KS
199: .ps -\n(tP
200: .vs -\n(tVu
201: .TS
202: center,box;
203: a | a .
204: byte use
205: = =
206: 0 maximum client message size
207: _ _
208: 1 client device number
209: _ _
210: 2 protocol type
211: _ _
212: 3 debug flag
213: _ _
214: 4-15 unused
215: .TE
216: .ps +\n(tP
217: .vs +\n(tVu
218: .KE
219: The maximum message size is currently set to 5K bytes. In the message,
220: the size is expressed in units of 1KB. The client can change the maximum
221: message size via an \fIioctl\fP (see \(sc5.1.2).
222: The device number is the major device number
223: of the client.
224: It is the same as the unique id obtained from the friends file.
225: The server creates device numbers using this major number. The minor number
226: is created on the fly and is unique among all device numbers the server has seen since
227: it started.
228: .PP
229: The protocol type is expressed as an ASCII character.
230: The currently supported protocols are
231: .CW t
232: (TCP byte streams) and
233: .CW d
234: (Datakit messages).
235: The debug flag determines the detail of the messages that get written to the log file.
236: .PP
237: The server responds to the first message with a one-byte response
238: containing the value 1.
239: .PP
240: The second network message read is \fImax_message_size\fP bytes long.
241: It contains the user ids from the client machine,
242: obtained from the client's password file. The entries are in ASCII, with the last entry
243: followed by a NULL.
244: The format of each entry in the message is:
245: .P1
246: user_name user_id\n
247: .P2
248: The server responds to this message with a one-byte response containing the value 2.
249: .PP
250: The user id message is parsed and a table is built mapping client user ids to server
251: user ids. Client and server hash lists map user ids to indices into the mapping table
252: to speed lookup operations.
253: .PP
254: The third network message read is also \fImax_message_size\fP bytes long.
255: It contains the group ids from the client machine,
256: obtained from the client's group file. The entries are in ASCII, with the last entry
257: followed by a NULL.
258: The format of each entry in the message is:
259: .P1
260: group_name group_id\n
261: .P2
262: The server responds to this message with a one-byte response containing the value 3.
263: .PP
264: The group id message is parsed and a table is built mapping client group ids to server
265: group ids. Client and server hash lists map group ids to indices into the mapping table
266: to speed lookup operations.
267: .PP
268: If there are too many user or group ids to fit in the message, the client does not
269: attempt to send the message to the server. Rather, the client closes the connection
270: and the server exits.
271: .PP
272: If everything is successful, the
273: server opens its root and creates an internal file entry mapping
274: its root to the client's mount point. The rest of the time is spent in a loop
275: servicing client requests.
276: .NH 1
277: File System Operations
278: .PP
279: The file system operations in Version 9 are:
280: .nr xx \\n(PDu
281: .nr PD 0.1v
282: .IP \fBmount\fP 8
283: mount and unmount the file system
284: .IP \fBput\fP
285: release an inode
286: .IP \fBget\fP
287: get an inode
288: .IP \fBfree\fP
289: free the disk space associated with the inode
290: .IP \fBupdat\fP
291: update the times on the inode
292: .IP \fBread\fP
293: read from the inode's file
294: .IP \fBwrite\fP
295: write to the inode's file
296: .IP \fBstat\fP
297: return the statistics on the inode's file
298: .IP \fBtrunc\fP
299: truncate the inode's file
300: .IP \fBnami\fP
301: parse a pathname
302: .IP \fBioctl\fP
303: file system-specific ioctls and device ioctls
304: .IP \fBopen\fP
305: open a device
306: .IP \fBdirread\fP
307: read a directory
308: .nr PD \\n(xxu
309: .PP
310: In the network file system, file system operations
311: consist of request/response messages. The client sends a message
312: to the server and blocks until the response comes back.
313: For historical reasons, the messages follow VAX-style byte ordering and
314: all network message structures are multiples of 8 bytes.
315: Messages sent from the client to the server are of the following format:
316: .KS
317: .ps -\n(tP
318: .vs -\n(tVu
319: .TS
320: center,box;
321: a .
322: message header
323: (struct sendb)
324: _
325: optional
326: operation-specific
327: header
328: _
329: optional
330: user data
331: .TE
332: .ps +\n(tP
333: .vs +\n(tVu
334: .KE
335: .PP
336: Throughout the rest of this paper, C structure definitions are used to describe
337: network messages. Elements of type \f(CWchar\fP are one byte long, elements of type
338: \f(CWshort\fP are two bytes long, and elements of type \f(CWlong\fP are four bytes long.
339: Fields are included to remove any ambiguity regarding structure padding.
340: .PP
341: The request message header is defined by a \f(CWstruct sendb\fP:
342: .P1
343: struct sendb {
344: char version;
345: char cmd;
346: char flags;
347: char rsva;
348: long trannum;
349: long len;
350: long tag;
351: short uid;
352: short gid;
353: long rsvb;
354: }
355: .P2
356: .PP
357: \f(CWversion\fP indicates which version of the protocol is in use.
358: \f(CWcmd\fP indicates the operation requested.
359: \f(CWrsva\fP and \f(CWrsvb\fP are pad fields.
360: \f(CWtrannum\fP is the transaction number for the message.
361: \f(CWlen\fP is the length of the message in bytes, including the headers and data.
362: \f(CWtag\fP is used to identify the file to which the operation pertains.
363: The tags are composed of the device number where the file lives shifted left 16 bits,
364: ORed with the inode number.
365: \f(CWuid\fP and \f(CWgid\fP are the user and group ids of the client generating the operation,
366: respectively.
367: .PP
368: Messages sent from the server to the client are of the following format:
369: .KS
370: .ps -\n(tP
371: .vs -\n(tVu
372: .TS
373: center,box;
374: a .
375: message header
376: (struct recvb)
377: _
378: optional
379: operation-specific
380: header
381: _
382: optional
383: user data
384: .TE
385: .ps +\n(tP
386: .vs +\n(tVu
387: .KE
388: .PP
389: The response message header is defined by a \f(CWstruct recvb\fP:
390: .P1
391: struct recvb {
392: long trannum;
393: short errno;
394: char flags;
395: char rsvd;
396: long len;
397: long fsize;
398: }
399: .P2
400: The server copies \f(CWtrannum\fP from the request message so the client can
401: match up responses with requests.
402: \f(CWerrno\fP is the error number if the operation failed, or 0 on success.
403: The \f(CWflags\fP field is used to indicate special conditions for certain operations.
404: \f(CWrsvd\fP is a pad field. \f(CWlen\fP is the
405: length of the message, including the headers and data. \f(CWfsize\fP is the file
406: size and is set only by the read, write, and dirread file system operations.
407: .PP
408: The following sections describe some details of the file system operations
409: for the network file system, including the content of messages exchanged between the client
410: and the server. There is no
411: .I nbopen ()
412: entry point.
413: Instead, a stub (\fInullopen\fP) is used, which is provided by the system.
414: This is because \fIzarf\fP opens the file as part of parsing the pathname, so no extra
415: protocol is necessary.
416: \fIZarf\fP does not fully support access to devices.
417: .NH 2
418: nbmount
419: .PP
420: When mounting the file system, the \fIflag\fP argument to
421: .I fmount (2)
422: contains the
423: device number for the remote file system.
424: The file descriptor passed to \fIfmount\fP is the client's end of the network
425: connection to the server.
426: The client side creates an inode for the root of the file system with this information.
427: .PP
428: When unmounting the file system, all active inodes on that file system
429: are converted to inodes in the error file system (errfs). This will cause all further
430: operations on them to fail, until the inodes are freed.
431: .NH 2
432: nbget
433: .PP
434: The information
435: in the inode is filled in by \fInbget\fP, called from \fInami\fP.
436: For the root inode, it can be called from \fInbmount\fP, so it
437: constructs the information by hand. However, for all other inodes, it fills
438: in the information with the cached data obtained from the previous nami message.
439: The nami cache is one entry long.
440: .X "PARM CT 70
441: .NH 2
442: nbput
443: .PP
444: If the inode is marked ICHG, \fInbupdat\fP is called.
445: Then a NBPUT message is sent
446: to the server. The format of the message is:
447: .KS
448: .ps -\n(tP
449: .vs -\n(tVu
450: .TS
451: center,box;
452: c s
453: a | a .
454: NBPUT request
455: =
456: sendb value
457: _ _
458: version 2
459: cmd NBPUT
460: flags 0
461: rsva unused
462: trannum transaction number
463: len sizeof(struct sendb)
464: (24 bytes)
465: tag tag of inode
466: uid uid of client
467: gid gid of client
468: rsvb unused
469: .TE
470: .ps +\n(tP
471: .vs +\n(tVu
472: .KE
473: .PP
474: For this operation, the server will search through its list of open files, matching on
475: \f(CWtag\fP.
476: If the file is found and it is not the root, then the server closes the file and invalidates
477: its entry in the list. The response sent back to the client is:
478: .KS
479: .ps -\n(tP
480: .vs -\n(tVu
481: .TS
482: center,box;
483: c s
484: a | a .
485: NBPUT response
486: =
487: recvb value
488: _ _
489: trannum transaction number
490: errno error number or 0
491: flags 0
492: rsvd unused
493: len sizeof(struct recvb)
494: (16 bytes)
495: fsize 0
496: .TE
497: .ps +\n(tP
498: .vs +\n(tVu
499: .KE
500: .X "PARM CT 50
501: .NH 2
502: nbfree
503: .PP
504: \fINbfree\fP is just a stub that doesn't do anything. Since the server removes
505: the disk space associated with a file during the nami NI_DEL and NI_RMDIR
506: operations, there is no need to do anything in \fInbfree\fP.
507: .NH 2
508: nbupdat
509: .PP
510: This operation invalidates the nami cache.
511: The message sent to the server contains an operation-specific header in the form of
512: a \f(CW struct snbup\fP:
513: .P1
514: struct snbup {
515: unsigned short mode;
516: short rdvdd;
517: long rsvd;
518: long ta;
519: long tm;
520: }
521: .P2
522: The \f(CWmode\fP is the mode of the file from the inode. \f(CWrdvdd\fP is currently unused.
523: \f(CWrsvd\fP is a pad field. \f(CWta\fP
524: is the access time on the client machine and \f(CWtm\fP is
525: the modify time on the client machine.
526: If the inode is not marked IACC, \f(CWta\fP is set to 0.
527: If the inode is not marked IUPD, \f(CWtm\fP is set to 0.
528: The message sent to the server is as follows:
529: .KS
530: .ps -\n(tP
531: .vs -\n(tVu
532: .TS
533: center,box;
534: c s
535: a | a .
536: NBUPD request
537: =
538: sendb value
539: _ _
540: version 2
541: cmd NBUPD
542: flags 0
543: rsva unused
544: trannum transaction number
545: len sizeof(struct sendb)+
546: sizeof(struct snbup)
547: (40 bytes)
548: tag tag of inode
549: uid uid of client
550: gid gid of client
551: rsvb unused
552: _ _
553: snbup value
554: _ _
555: mode mode of inode
556: rdvdd unused
557: rsvd unused
558: ta access time or 0
559: tm modify time or 0
560: .TE
561: .ps +\n(tP
562: .vs +\n(tVu
563: .KE
564: .PP
565: If the times are zero in the client request message, the server obtains the times
566: from the cached
567: .I stat (2)
568: information for the file. Otherwise the times from the message
569: are adjusted with a time drift correction (see \(sc5.8).
570: The access and modify times are updated via
571: .I utime (2).
572: If the modes
573: are to be changed, and the client process owns the file, they are updated with either
574: .I fchmod (2)
575: or
576: .I chmod (2).
577: The server responds to the client with the following message:
578: .KS
579: .ps -\n(tP
580: .vs -\n(tVu
581: .TS
582: center,box;
583: c s
584: a | a .
585: NBUPD response
586: =
587: recvb value
588: _ _
589: trannum transaction number
590: errno error number or 0
591: flags 0
592: rsvd unused
593: len sizeof(struct recvb)
594: (16 bytes)
595: fsize 0
596: .TE
597: .ps +\n(tP
598: .vs +\n(tVu
599: .KE
600: ........
601: .NH 2
602: nbread
603: .PP
604: This operation invalidates the nami cache.
605: The client sends multiple messages to the server, reading at most \fImax_message_size\fP-16
606: bytes at a time (currently 5104 bytes).
607: .PP
608: The message sent to the server includes an operation-specific \f(CWsnbread\fP structure:
609: .P1
610: struct snbread {
611: long len;
612: long offset;
613: }
614: .P2
615: \f(CWlen\fP is the number of bytes to be read and \f(CWoffset\fP is the offset in
616: the file at which the read should start. The message sent to the server is as follows:
617: .KS
618: .ps -\n(tP
619: .vs -\n(tVu
620: .TS
621: center,box;
622: c s
623: a | a .
624: NBREAD request
625: =
626: sendb value
627: _ _
628: version 2
629: cmd NBREAD
630: flags 0
631: rsva unused
632: trannum transaction number
633: len sizeof(struct sendb)+
634: sizeof(struct snbread)
635: (32 bytes)
636: tag tag of inode
637: uid uid of client
638: gid gid of client
639: rsvb unused
640: _ _
641: snbread value
642: _ _
643: len number of bytes to read
644: offset byte offset where to start
645: reading
646: .TE
647: .ps +\n(tP
648: .vs +\n(tVu
649: .KE
650: .PP
651: The server reads the data and sends it back to the client. When all of
652: the data is read, or
653: .I read (2)
654: returns less than the amount asked for, the \f(CWflags\fP
655: field is set to NBEND.
656: The message sent from the server to the client is:
657: .KS
658: .ps -\n(tP
659: .vs -\n(tVu
660: .TS
661: center,box;
662: c s
663: a | a .
664: NBREAD response
665: =
666: recvb value
667: _ _
668: trannum transaction number
669: errno error number or 0
670: flags 0 or NBEND
671: rsvd unused
672: len sizeof(struct recvb)+
673: number of bytes read
674: fsize size of attempted read
675: _ _
676: data read from file
677: .TE
678: .ps +\n(tP
679: .vs +\n(tVu
680: .KE
681: .NH 2
682: nbwrite
683: .PP
684: This operation invalidates the nami cache.
685: The client sends multiple messages to the server, writing at most \fImax_message_size\fP-32
686: bytes at a time (currently 5088 bytes).
687: The message sent to the server includes an operation-specific \f(CWsnbwrite\fP structure:
688: .P1
689: struct snbwrite {
690: long len;
691: long offset;
692: }
693: .P2
694: \f(CWlen\fP is the number of bytes to be written and \f(CWoffset\fP is the offset in
695: the file at which the write should start. The message sent to the server is as follows:
696: .KS
697: .ps -\n(tP
698: .vs -\n(tVu
699: .TS
700: center,box;
701: c s
702: a | a .
703: NBWRT request
704: =
705: sendb value
706: _ _
707: version 2
708: cmd NBWRT
709: flags 0
710: rsva unused
711: trannum transaction number
712: len sizeof(struct sendb)+
713: sizeof(struct snbwrite)+
714: number of bytes to write
715: tag tag of inode
716: uid uid of client
717: gid gid of client
718: rsvb unused
719: _ _
720: snbwrite value
721: _ _
722: len number of bytes to write
723: offset byte offset where to
724: start writing
725: _ _
726: data to be written
727: .TE
728: .ps +\n(tP
729: .vs +\n(tVu
730: .KE
731: The client marks the inode (IUPD|ICHG). After the write, the server seeks to
732: the end of the file and updates the size of the file. The message sent back to the client is:
733: .KS
734: .ps -\n(tP
735: .vs -\n(tVu
736: .TS
737: center,box;
738: c s
739: a | a .
740: NBWRT response
741: =
742: recvb value
743: _ _
744: trannum transaction number
745: errno error number or 0
746: flags 0
747: rsvd unused
748: len sizeof(struct recvb)
749: (16 bytes)
750: fsize file size
751: .TE
752: .ps +\n(tP
753: .vs +\n(tVu
754: .KE
755: The client updates the size of the file in the inode with \f(CWfsize\fP.
756: .NH 2
757: nbstat
758: .PP
759: The client maintains a one-entry cache from nami processing to avoid
760: sending a stat message to the server immediately after a nami operation.
761: If the client cache entry is valid, the
762: .I stat (2)
763: is satisfied from the
764: cached data. Otherwise a message is sent to the server. The operation-specific
765: part of the message contains a \f(CWsnbstat\fP structure:
766: .P1
767: struct snbstat {
768: long ta;
769: long rsvd;
770: }
771: .P2
772: \f(CWta\fP is the current time on the client and is used for synchronization.
773: \f(CWrsvd\fP is a pad field. The message sent from the client to the server is:
774: .KS
775: .ps -\n(tP
776: .vs -\n(tVu
777: .TS
778: center,box;
779: c s
780: a | a .
781: NBSTAT request
782: =
783: sendb value
784: _ _
785: version 2
786: cmd NBSTAT
787: flags 0
788: rsva unused
789: trannum transaction number
790: len sizeof(struct sendb)+
791: sizeof(struct snbstat)
792: (32 bytes)
793: tag tag of inode
794: uid uid of client
795: gid gid of client
796: rsvb unused
797: _ _
798: snbstat value
799: _ _
800: ta current time on client
801: rsvd unused
802: .TE
803: .ps +\n(tP
804: .vs +\n(tVu
805: .KE
806: .PP
807: After each of the first three stat messages, and
808: after every third stat message thereafter, the server recalculates the time drift between the
809: client machine and the server machine. The server uses
810: .I fstat (2) to obtain the
811: information about the given file.
812: The response message sent to the client has an operation-specific header
813: that contains a \f(CWrnbstat\fP structure:
814: .P1
815: struct rnbstat {
816: long ino;
817: short dev;
818: short mode;
819: short nlink;
820: short uid, gid;
821: short rdev;
822: long size;
823: long ta;
824: long tm;
825: long tc;
826: };
827: .P2
828: The response message is as follows:
829: .KS
830: .ps -\n(tP
831: .vs -\n(tVu
832: .TS
833: center,box;
834: c s
835: a | a .
836: NBSTAT response
837: =
838: recvb value
839: _ _
840: trannum transaction number
841: errno error number or 0
842: flags 0
843: rsvd unused
844: len sizeof(struct recvb)+
845: sizeof(struct rnbstat)
846: (48 bytes)
847: fsize 0
848: _ _
849: rnbstat value
850: _ _
851: ino inode number
852: dev device number
853: mode mode of file
854: nlink number of links to file
855: uid owner of file
856: gid group of file
857: rdev unused
858: size size of file
859: ta access time
860: tm modify time
861: tc change time
862: .TE
863: .ps +\n(tP
864: .vs +\n(tVu
865: .KE
866: .NH 2
867: nbtrunc
868: .PP
869: \fINbtrunc\fP invalidates the nami cache.
870: The message sent to the server is as follows:
871: .KS
872: .ps -\n(tP
873: .vs -\n(tVu
874: .TS
875: center,box;
876: c s
877: a | a .
878: NBTRNC request
879: =
880: sendb value
881: _ _
882: version 2
883: cmd NBTRNC
884: flags 0
885: rsva unused
886: trannum transaction number
887: len sizeof(struct sendb)
888: (24 bytes)
889: tag tag of inode
890: uid uid of client
891: gid gid of client
892: rsvb unused
893: .TE
894: .ps +\n(tP
895: .vs +\n(tVu
896: .KE
897: .PP
898: The client must own the file to be allowed to truncate it. The server uses
899: .I creat (2)
900: to truncate the file. Since
901: .I creat
902: also opens the file
903: for writing, the server immediately closes it. The message sent back to the
904: client is:
905: .KS
906: .ps -\n(tP
907: .vs -\n(tVu
908: .TS
909: center,box;
910: c s
911: a | a .
912: NBTRNC response
913: =
914: recvb value
915: _ _
916: trannum transaction number
917: errno error number or 0
918: flags nami flags
919: rsvd unused
920: len sizeof(struct recvb)
921: (16 bytes)
922: fsize 0
923: .TE
924: .ps +\n(tP
925: .vs +\n(tVu
926: .KE
927: .NH 2
928: nbnami
929: .PP
930: The file system-specific nami performs a number of operations.
931: It can parse a pathname, link a file, unlink a file,
932: make a directory, remove a directory, and create a file.
933: The message sent to the server contains an operation-specific header in the form
934: of a \f(CWsnbnami\fP structure:
935: .P1
936: struct snbnami {
937: short mode;
938: short dev;
939: long ino;
940: }
941: .P2
942: The message sent to the server is as follows:
943: .KS
944: .ps -\n(tP
945: .vs -\n(tVu
946: .TS
947: center,box;
948: c s
949: a | a .
950: NBNAMI request
951: =
952: sendb value
953: _ _
954: version 2
955: cmd NBNAMI
956: flags nami operation
957: rsva unused
958: trannum transaction number
959: len sizeof(struct sendb)+
960: sizeof(struct snbnami)+
961: number of bytes in the
962: pathname
963: tag tag of inode
964: uid uid of client
965: gid gid of client
966: rsvb unused
967: _ _
968: snbnami value
969: _ _
970: mode mode of inode for
971: NI_CREAT, NI_NXCREAT,
972: and NI_MKDIR
973: dev unused
974: ino inode number (tag) for
975: NI_LINK
976: _ _
977: data full pathname
978: .TE
979: .ps +\n(tP
980: .vs +\n(tVu
981: .KE
982: The \f(CWflags\fP field determines what the server should do.
983: While parsing the pathname, if it goes out of the remote file system, the server
984: sets the \f(CWflags\fP field in the response message to NBROOT and sends the message
985: back to the client so the
986: client can continue with pathname evaluation. Each nami operation is described in the
987: following sections.
988: .X "PARM CT 60
989: .PP
990: The response message sent back to the client contains a \f(CWrnbnami\fP structure:
991: .P1
992: struct rnbnami {
993: long tag;
994: long ino;
995: short dev;
996: short mode;
997: long used;
998: short nlink;
999: short uid, gid;
1000: short rdev;
1001: long size;
1002: long ta;
1003: long tm;
1004: long tc;
1005: };
1006: .P2
1007: The message is as follows:
1008: .KS
1009: .ps -\n(tP
1010: .vs -\n(tVu
1011: .TS
1012: center,box;
1013: c s
1014: a | a .
1015: NBNAMI response
1016: =
1017: recvb value
1018: _ _
1019: trannum transaction number
1020: errno error number or 0
1021: flags 0 or NBROOT
1022: rsvd unused
1023: len sizeof(struct recvb)+
1024: sizeof(struct rnbnami)
1025: (56 bytes)
1026: fsize 0
1027: _ _
1028: rnbnami value
1029: _ _
1030: tag tag
1031: ino inode number
1032: dev device number
1033: mode mode of file
1034: used if NBROOT, number of bytes
1035: parsed in pathname
1036: nlink number of links to file
1037: uid owner of file
1038: gid group of file
1039: rdev unused
1040: size size of file
1041: ta access time
1042: tm modify time
1043: tc change time
1044: .TE
1045: .ps +\n(tP
1046: .vs +\n(tVu
1047: .KE
1048: .PP
1049: If the pathname evaluates to a file on the server's file system, then the server
1050: will perform different tasks based on the value of \f(CWflags\fP in the request message.
1051: .NH 3
1052: NI_SEARCH
1053: .PP
1054: The server opens the file and sends the response message to the client.
1055: .NH 3
1056: NI_DEL
1057: .PP
1058: If the client process has write permission in the directory containing the file, and if
1059: the file is a regular file, then the server attempts to
1060: .I unlink (2)
1061: it.
1062: If the file is a directory, the server tries to remove it with
1063: .I rmdir (2)
1064: instead. Other
1065: file types cannot be deleted.
1066: .NH 3
1067: NI_CREAT
1068: .PP
1069: The server creates (and truncates) the file with
1070: .I creat (2).
1071: For
1072: new file creation, the server does not allow special files or symbolic links
1073: to be created.
1074: .NH 3
1075: NI_NXCREAT
1076: .PP
1077: This does the same thing as NI_CREAT, but if the file already exists, it
1078: fails with EEXIST.
1079: .NH 3
1080: NI_LINK
1081: .PP
1082: If the file already exists, the server fails the operation with EEXIST.
1083: Otherwise, the server uses
1084: .I link (2)
1085: to link the filename to the file
1086: represented by the client inode given by \f(CWino\fP.
1087: .NH 3
1088: NI_MKDIR
1089: .PP
1090: If the file (directory) already exists, the server fails the operation with EEXIST.
1091: If the server has write permissions in the parent directory, then a new directory
1092: is created with
1093: .I mkdir (2).
1094: .NH 3
1095: NI_RMDIR
1096: .PP
1097: This does the same thing as NI_DEL, but deals only with removing directories.
1098: .NH 2
1099: nbdirread
1100: .PP
1101: This operation is used to read a directory and present the contents in a canonical form.
1102: The form is a NULL-terminated character string containing the i-number in decimal, a
1103: tab, and the filename.
1104: .PP
1105: The client sends one message to the server, reading at most \fImax_message_size\fP-24
1106: bytes at a time (5096 bytes).
1107: The message sent to the server contains an operation-specific header in the form
1108: of a \f(CWsnbread\fP structure (see \(sc5.6).
1109: The message is as follows:
1110: .KS
1111: .ps -\n(tP
1112: .vs -\n(tVu
1113: .TS
1114: center,box;
1115: c s
1116: a | a .
1117: NBDIR request
1118: =
1119: sendb value
1120: _ _
1121: version 2
1122: cmd NBDIR
1123: flags 0
1124: rsva unused
1125: trannum transaction number
1126: len sizeof(struct sendb)+
1127: sizeof(struct snbread)
1128: (32 bytes)
1129: tag tag of inode
1130: uid uid of client
1131: gid gid of client
1132: rsvb unused
1133: _ _
1134: snbread value
1135: _ _
1136: len number of bytes to read
1137: offset byte offset where to
1138: start reading
1139: .TE
1140: .ps +\n(tP
1141: .vs +\n(tVu
1142: .KE
1143: .PP
1144: The server reads the directory and responds back with a message containing the directory
1145: contents and an operation-specific header in the form of a \f(CWrnbdir\fP structure:
1146: .P1
1147: struct rnbdir {
1148: long used;
1149: long rsvd;
1150: };
1151: .P2
1152: The response message is as follows:
1153: .KS
1154: .ps -\n(tP
1155: .vs -\n(tVu
1156: .TS
1157: center,box;
1158: c s
1159: a | a .
1160: NBDIR response
1161: =
1162: recvb value
1163: _ _
1164: trannum transaction number
1165: errno error number or 0
1166: flags 0
1167: rsvd unused
1168: len sizeof(struct recvb)+
1169: sizeof(struct rnbdir)
1170: (24 bytes)
1171: fsize size of attempted read
1172: _ _
1173: rnbdir value
1174: _ _
1175: used bytes read
1176: rsvd unused
1177: _ _
1178: data directory entries
1179: .TE
1180: .ps +\n(tP
1181: .vs +\n(tVu
1182: .KE
1183: .PP
1184: On success, \f(CWused\fP contains the number of bytes read. It is added to \f(CWu.u_offset\fP
1185: to get the new offset in the directory.
1186: .NH 2
1187: nbioctl
1188: .PP
1189: The client side supports three
1190: .I ioctl (2)
1191: commands private to
1192: the file system type. NBIOCON turns debugging on, NBIOCOFF turns
1193: debugging off, and NBIOCBSZ changes the network message size.
1194: All other commands are sent to the server. It is assumed that all
1195: .I ioctl s
1196: contain a 64-byte buffer of data needed for the operation.
1197: Data are copied in from the buffer to send to the server and any resulting data
1198: are copied out to the buffer if the operation succeeds.
1199: The message sent to the server contains an operation-specific header in the form
1200: of a \f(CWsnbioc\fP structure:
1201: .P1
1202: struct snbioc {
1203: long cmd;
1204: short flag;
1205: short rsvd;
1206: }
1207: .P2
1208: The message sent to the server is:
1209: .KS
1210: .ps -\n(tP
1211: .vs -\n(tVu
1212: .TS
1213: center,box;
1214: c s
1215: a | a .
1216: NBIOCTL request
1217: =
1218: sendb value
1219: _ _
1220: version 2
1221: cmd NBIOCTL
1222: flags 0
1223: rsva unused
1224: trannum transaction number
1225: len sizeof(struct sendb)+
1226: sizeof(struct snbioc)+
1227: 64 bytes of user data
1228: (96 bytes)
1229: tag tag of inode
1230: uid uid of client
1231: gid gid of client
1232: rsvb unused
1233: _ _
1234: snbioc value
1235: _ _
1236: cmd ioctl command
1237: flag file table flags
1238: rsvd unused
1239: _ _
1240: data from user ioctl buffer
1241: .TE
1242: .ps +\n(tP
1243: .vs +\n(tVu
1244: .KE
1245: The response message sent from the server to the client is:
1246: .KS
1247: .ps -\n(tP
1248: .vs -\n(tVu
1249: .TS
1250: center,box;
1251: c s
1252: a | a .
1253: NBIOCTL response
1254: =
1255: recvb value
1256: _ _
1257: trannum transaction number
1258: errno error number or 0
1259: flags 0
1260: rsvd unused
1261: len sizeof(struct recvb)+
1262: 64 bytes of user data
1263: (80 bytes)
1264: fsize 0
1265: _ _
1266: data for user ioctl buffer
1267: .TE
1268: .ps +\n(tP
1269: .vs +\n(tVu
1270: .KE
1271: .PP
1272: Currently, \fIzarf\fP does not support \fIioctl\fP and returns ENOTTY for
1273: this operation.
1274: .X PARM CT 50
1275: .NH 1
1276: Permissions
1277: .PP
1278: The server determines permissions by matching passwd and group files.
1279: Exceptions to the default permissions can be found in
1280: .CW /usr/netb/except.local
1281: and
1282: .CW /usr/netb/except .
1283: The format of these files are comment lines begin with
1284: .CW # ,
1285: blank lines are ignored, and lines may contain one of four valid directives.
1286: .PP
1287: The
1288: .CW client
1289: directive specifies the client to which the following lines apply:
1290: .P1
1291: client \fICLIENT_NAME
1292: .P2
1293: where \fICLIENT_NAME\fP is the name of the client machine, or
1294: .CW *
1295: for all clients that
1296: do not have an explicit entry. The client name is separated from the keyword
1297: by spaces or tabs.
1298: .PP
1299: The
1300: .CW uid
1301: directive specifies how to map a given user:
1302: .P1
1303: uid \fICLIENT_USR_NAME\fP=\fISERVER_USR_NAME
1304: .P2
1305: where \fICLIENT_USR_NAME\fP is the name of a user on the client machine and
1306: \fISERVER_USR_NAME\fP is the name of a user on the server machine to which the client
1307: is mapped. \fISERVER_USR_NAME\fP
1308: may be left out signifying the client is not to be mapped (i.e. disallowed access.)
1309: .PP
1310: The
1311: .CW gid
1312: directive specifies how to map a given group:
1313: .P1
1314: gid \fICLIENT_GRP_NAME\fP=\fISERVER_GRP_NAME
1315: .P2
1316: where \fICLIENT_GRP_NAME\fP is the name of a group on the client machine and
1317: \fISERVER_GRP_NAME\fP
1318: is the name of a group on the server machine to which the client is mapped.
1319: \fISERVER_GRP_NAME\fP
1320: may be left out signifying the client is not to be mapped (i.e. disallowed access.)
1321: .PP
1322: The
1323: .CW param
1324: directive conveys specific parameters to the server:
1325: .P1
1326: param \fINAME\fP=\fIVALUE
1327: .P2
1328: The following parameters
1329: .I NAME ) (
1330: are supported:
1331: .IP \f(CWotherok\fP 10
1332: this may take on a value of either 0 or 1. A value of 1 gives read
1333: permissions to client ids that are not mapped and a value of 0 denies access. In either
1334: case, client ids that are not mapped are denied write access.
1335: .IP \f(CWroot\fP
1336: the value for this parameter is the pathname of the root from
1337: which the server will execute.
1338: .NH 1
1339: Acknowledgements
1340: .PP
1341: Peter Weinberger originally wrote the network file system.
1342: More recently, Norman
1343: Wilson has fixed bugs and rewritten \fIzarf\fP and \fIsetup\fP.
1344: He greatly improved the
1345: portability of \fIzarf\fP. Thanks to Peter Honeyman, Dennis Ritchie, and Norman
1346: Wilson for reviewing this paper.
1347: .NH 1
1348: References
1349: .LP
1350: |reference_placement
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.