1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
|
.\"
.\" nfsd(7) - The nfsd filesystem
.\"
.\" Copyright (C) 2003 Neil Brown <neilb@cse.unsw.edu.au>
.\" Licensed for public use under the terms of the FSF
.\" General Public License (GPL) version 2.
.TH nfsd 7 "3 July 2003"
.SH NAME
nfsd \- special filesystem for controlling Linux NFS server
.SH SYNPOSIS
.B "mount -t nfsd nfsd /proc/fs/nfsd"
.SH DESCRIPTION
The
.B nfsd
filesystem is a special filesystem which provides access to the Linux
NFS server. Writing to files in this filesystem can affect the server.
Reading from them can provide information about the server.
.P
As well as this filesystem, there are a collection of files in the
.B procfs
filesystem (normally mounted at
.BR /proc )
which are used to control the NFS server.
This manual page describes all of these files.
.P
The
.I exportfs
and
.I mountd
programs (part of the nfs-utils package) expect to find this
filesystem mounted at
.B /proc/fs/nfsd
or
.BR /proc/fs/nfs .
.SH DETAILS
Files in the
.B nfsd
filesystem include:
.TP
.B exports
This file contains a list of filesystems that are currently exported
and clients that each filesystem is exported to, together with a list
of export options for that client/filesystem pair. This is similar
to the
.B /proc/fs/nfs/exports
file in 2.4.
One difference is that a client doesn't necessarily correspond to just
one host. It can respond to a large collection of hosts that are
being treated identically.
Each line of the file contains a path name, a client name, and a
number of options in parentheses. Any space, tab, newline or
back-slash character in the path name or client name will be replaced
by a backslash followed by the octal ASCII code for that character.
.TP
.B threads
This file represents the number of
.B nfsd
thread currently running. Reading it will show the number of
threads. Writing an ASCII decimal number will cause the number of
threads to be changed (increased or decreased as necessary) to achieve
that number.
.TP
.B filehandle
This is a somewhat unusual file in that what is read from it depends
on what was just written to it. It provides a transactional interface
where a program can open the file, write a request, and read a
response. If two separate programs open, write, and read at the same
time, their requests will not be mixed up.
The request written to
.B filehandle
should be a client name, a path name, and a number of bytes. This
should be followed by a newline, with white-space separating the
fields, and octal quoting of special characters.
On writing this, the program will be able to read back a filehandle
for that path as exported to the given client. The filehandle's length
will be at most the number of bytes given.
The filehandle will be represented in hex with a leading '\ex'.
.TP
.B clients/
This directory contains a subdirectory for each NFSv4 client. Each file
under that subdirectory gives some details about the client in YAML
format. In addition, writing "expire\\n" to the
.B ctl
file will force the server to immediately revoke all state held by that
client.
.PP
The directory
.B /proc/net/rpc
in the
.B procfs
filesystem contains a number of files and directories.
The files contain statistics that can be display using the
.I nfsstat
program.
The directories contain information about various caches that the NFS
server maintains to keep track of access permissions that different
clients have for different filesystems.
The caches are:
.TP
.B auth.unix.ip
This cache contains a mapping from IP address to the name of the
authentication domain that the ipaddress should be treated as part of.
.TP
.B nfsd.export
This cache contains a mapping from directory and domain to export
options.
.TP
.B nfsd.fh
This cache contains a mapping from domain and a filesystem identifier
to a directory. The filesystem identifier is stored in the
filehandles and consists of a number indicating the type of identifier
and a number of hex bytes indicating the content of the identifier.
.PP
Each directory representing a cache can hold from 1 to 3 files. They
are:
.TP
.B flush
When a number of seconds since epoch (1 Jan 1970) is written to this
file, all entries in the cache that were last updated before that file
become invalidated and will be flushed out. Writing a time in the
future (in seconds since epoch) will flush
everything. This is the only file that will always be present.
.TP
.B content
This file, if present, contains a textual representation of ever entry
in the cache, one per line. If an entry is still in the cache
(because it is actively being used) but has expired or is otherwise
invalid, it will be presented as a comment (with a leading hash
character).
.TP
.B channel
This file, if present, acts a channel for request from the kernel-based
nfs server to be passed to a user-space program for handling.
When the kernel needs some information which isn't in the cache, it
makes a line appear in the
.B channel
file giving the key for the information. A user-space program should
read this, find the answer, and write a line containing the key, an
expiry time, and the content.
For example the kernel might make
.ti +5
nfsd 127.0.0.1
.br
appear in the
.B auth.unix.ip/content
file. The user-space program might then write
.ti +5
nfsd 127.0.0.1 1057206953 localhost
.br
to indicate that 127.0.0.1 should map to localhost, at least for now.
If the program uses select(2) or poll(2) to discover if it can read
from the
.B channel
then it will never see and end-of-file but when all requests have been
answered, it will block until another request appears.
.PP
In the
.B /proc
filesystem there are 4 files that can be used to enabled extra tracing
of nfsd and related code. They are:
.in +5
.B /proc/sys/sunrpc/nfs_debug
.br
.B /proc/sys/sunrpc/nfsd_debug
.br
.B /proc/sys/sunrpc/nlm_debug
.br
.B /proc/sys/sunrpc/rpc_debug
.br
.in -5
They control tracing for the NFS client, the NFS server, the Network
Lock Manager (lockd) and the underlying RPC layer respectively.
Decimal numbers can be read from or written to these files. Each
number represents a bit-pattern where bits that are set cause certain
classes of tracing to be enabled. Consult the kernel header files to
find out what number correspond to what tracing.
.SH NOTES
This file system is only available in Linux 2.6 and later series
kernels (and in the later parts of the 2.5 development series leading
up to 2.6). This man page does not apply to 2.4 and earlier.
.P
Previously the nfsctl systemcall was used for communication between nfsd
and user utilities. That systemcall was removed in kernel version 3.1.
Older nfs-utils versions were able to fall back to nfsctl if necessary;
that was removed from nfs-utils 1.3.5.
.SH SEE ALSO
.BR nfsd (8),
.BR rpc.nfsd (8),
.BR exports (5),
.BR nfsstat (8),
.BR mountd (8)
.BR exportfs (8).
.SH AUTHOR
NeilBrown
|