Lines Matching +full:server +full:- +full:side
9 server to reliably handshake to determine if they are on the same
10 host. Select "NFS client and server support for LOCALIO auxiliary
14 Once an NFS client and server handshake as "local", the client will
26 But unlike the LOCALIO protocol, the sockaddr-based matching didn't
29 The robust handshake between local client and server is just the
32 directly to the server without having to go over the network. The
36 server.
42 - With LOCALIO:
48 - Without LOCALIO:
55 - With LOCALIO:
61 - Without LOCALIO:
72 a. Workloads where the NFS client and server are on the same host
75 running on the same host as the knfsd server being used for
83 b. Allow client and server to autonomously discover if they are
93 deciding if the NFS client and server are co-located on the same
98 server. This sets up a requirement for a handshake protocol that
100 identify that the client and the server really are running on the
103 in shared kernel memory if they are truly co-located.
108 advantage of NFS client and server locality. Policy that initiates
109 client IO as closely to the server where the data is stored naturally
115 onus on the server to somehow discover that the client is co-located
122 6. Why is having the client perform a server-side file OPEN, without
131 client perform a server-side file open, without using RPC, is ideal.
137 works by establishing a context that is cached by the server, and
151 as they do for non-LOCALIO.
156 See the detailed "NFS Client and Server Interlock" section below.
163 NFS server can see the nonce (single-use UUID) the client generated and
165 standard, nor does it need to be considering it is Linux-to-Linux
174 by IANA, see https://www.iana.org/assignments/rpc-program-numbers/ ):
196 NFS Common and Client/Server Handshake
200 to generate a nonce (single-use UUID) and associated short-lived
202 verification by the NFS server and if matched the NFS server populates
204 transfer the nfs_uuid_t from its nfs_uuids to the nn->nfsd_serv
210 (e.g. 'net' is the server's network namespace, through it the client can
211 access nn->nfsd_serv with proper rcu read access). It is this client
212 and server synchronization that enables advanced usage and lifetime of
213 objects to span from the host kernel's nfsd to per-container knfsd
217 NFS Client and Server Interlock
221 allow proper network namespace (net-ns) and NFSD object refcounting:
223 We don't want to keep a long-term counted reference on each NFSD's
224 net-ns in the client because that prevents a server container from
227 So we avoid taking a reference at all and rely on the per-cpu
228 reference to the server (detailed below) being sufficient to keep
229 the net-ns active. This involves allowing the NFSD's net-ns exit
230 code to iterate all active clients and clear their ->net pointers
231 (which are needed to find the per-cpu-refcount for the nfsd_serv).
235 - Embed nfs_uuid_t in nfs_client. nfs_uuid_t provides a list_head
236 that can be used to find the client. It does add the 16-byte
238 uuid_t is only used during the initial NFS client and server
242 - When the nfs server confirms that the uuid_t is local, it moves
243 the nfs_uuid_t onto a per-net-ns list in NFSD's nfsd_net.
245 - When each server's net-ns is shutting down - in a "pre_exit"
246 handler, all these nfs_uuid_t have their ->net cleared. There is
248 handlers so any caller that sees nfs_uuid_t ->net as not NULL can
249 safely manage the per-cpu-refcount for nfsd_serv.
251 - The client's nfs_uuid_t is passed to nfsd_open_local_fh() so it
252 can safely dereference ->net in a private rcu_read_lock() section
257 nn->nfsd_serv is not destroyed while in use by nfsd_open_local_fh(), and
262 reference for the nfsd_file and associated nn->nfsd_serv using
267 NFSD's net-ns (and nfsd_net by association) may have been destroyed
268 by nfsd_destroy_serv() via nfsd_shutdown_net() -- which is only
269 possible given the nfs_uuid_t ->net pointer managemenet detailed
272 All told, this elaborate interlock of the NFS client and server has been
278 nn->nfsd_serv, without having a proper reference on nn->nfsd_serv.
280 NFS Client issues IO instead of Server
289 focused use of select nfs server objects to allow a client local to a
290 server to open a file pointer without needing to go over the network.
293 server's fs/nfsd/localio.c:nfsd_open_local_fh() and carefully access
294 both the associated nfsd network namespace and nn->nfsd_serv in terms of
296 nfsd objects (be it struct net or nn->nfsd_serv) it returns -ENXIO
304 done by the nfs server). As such, for these operations, the NFS client
306 the NFS server. See: fs/nfs/localio.c:nfs_local_doio() and
309 With normal NFS that makes use of RPC to issue IO to the server, if an
311 the NFS server will not. Because the NFS server's use of buffered IO
325 Localio is only supported when UNIX-style authentication (AUTH_UNIX, aka
331 NFS client access to the NFS server is also used for LOCALIO.
334 namespace the server has. This is required to allow the client to access
335 the server's per-namespace nfsd_net struct. With traditional NFS, the
338 altered or purposely extended from the server to the client.
346 - Client and server both on the same host.
348 - All permutations of client and server support enablement for both
349 local and remote client and server.
351 - Testing against NFS storage products that don't support the LOCALIO
354 - Client on host, server within a container (for both v3 and v4.2).
358 - Formalizing these test scenarios in terms of existing test
359 infrastructure is on-going. Initial regular coverage is provided in
360 terms of ktest running xfstests against a LOCALIO-enabled NFS loopback
362 https://evilpiepirate.org/~testdashboard/ci?user=snitzer&branch=snitm-nfs-next
365 - Various kdevops testing (in terms of "Chuck's BuildBot") has been
367 regressions to non-LOCALIO NFS use cases.
369 - All of Hammerspace's various sanity tests pass with LOCALIO enabled