Summary:
By moving the work to a background threadpool, we can more quickly go back to
servicing incoming NFS requests and thus allow more work to be done
concurrently. This would allow tools like ripgrep to being able to use multiple
cores to search in the code base.
Reviewed By: genevievehelsel
Differential Revision: D27194040
fbshipit-source-id: 7f1775ddaaa7eaf8776a06d05951cb936cd3fbb5
Summary:
The Appender API doesn't allow us to simply append an IOBuf chain to it forcing
the entire chain to be copied to it. For the most part, this isn't an issue,
but to reduce the overhead of the READ NFS procedure, this will be a nice
benefit.
For the most part, this diff is a codemod, with a couple of places that needed
to be manually fixed. These were in the rpc/Server.{cpp,h} and
rpc/StreamClient.{cpp,h}.
Reviewed By: genevievehelsel
Differential Revision: D26675988
fbshipit-source-id: 04feef8623fcddd02ff7aea0b68a17598ab1d0f8
Summary:
Using the current EventBase can lead to unexpected behavior when the RpcServer
is created on the wrong thread. For instance, if it is created on a thread
pool, and another future is running on that same thread, the RpcServer won't be
able to accept and service new connections, potentially leading to deadlocks.
To avoid this, EdenFS's EventBase is excplicitely passed in, this will ensure
that the RpcServer is created on the proper thread.
Reviewed By: kmancini
Differential Revision: D26266145
fbshipit-source-id: 23211e3aa200c32d2f6fbbfd9ae6fb307896a873
Summary:
MSVC is broken as it doesn't understand the various macros used to generate
XdrTrait for specific types, and I can't figure out a way to make that work.
Even if I provide dummy version of these, the buck build breaks due to glog
trying to redefine the ERROR symbol that some Microsoft headers contain. For
now, let's just ifdef it out since it's unlikely that we're going to be using
NFS on Windows anytime soon.
Reviewed By: singhsrb
Differential Revision: D26293519
fbshipit-source-id: bbaf325c7d1f1688327708360244797a6d48179e
Summary: That way the NFS procedure won't clash with it.
Reviewed By: genevievehelsel
Differential Revision: D26159845
fbshipit-source-id: 22ce07326f9ec42aa9d44352ae5bb71368337c03
Summary:
For now, this only registers itself against rpcbind and always reply that the
procedure is unavailable. In the future, this will service all the procedures
and forward them to a Dispatcher.
Reviewed By: genevievehelsel
Differential Revision: D26159844
fbshipit-source-id: 21908f1333ed41b3eea3fb5ce19c8e68391df103
Summary:
In the NFS spec, the fhandle3 is defined as an opaque byte array, and thus its
size must preceed its content. Let's also move it to an NfsdRpc.h as this type
will be predominantly used by the Nfsd RPC program.
Reviewed By: chadaustin
Differential Revision: D26152812
fbshipit-source-id: 0cc37325078a2c7b58551eaa5177436b21e03838
Summary:
Now that we have the list of available mount points, we can properly reply to
the MNT RPC call.
Reviewed By: kmancini
Differential Revision: D26152810
fbshipit-source-id: f364292ead321689fb20f858aee45efdfbd7287d
Summary:
For a proper NFS server, rpcbind is used to query and collect the port/protocol
of the mountd and nfs programs at mount time. In EdenFS, the mount.nfs command
will be run by EdenFS directly, against itself, and we can manually specify
what the ports are for both the mountd and nfs programs. Thus we can use these
directly to avoid polluting the rpcbind database, and potentially conflicting
with a real NFS server.
This will be particularly useful when testing EdenFS as this allows multiple
tests to run at the same time.
Reviewed By: kmancini
Differential Revision: D26140416
fbshipit-source-id: 6b8aa22e69f580a9d6f6edf775d268809a909118
Summary:
Once everything is plugged in, EdenFS will first register the mount point with
Mountd, and then execute the mount.nfs CLI against itself to mount the
repository with the OS.
For now, this does the first part by simply informing Mountd of a new mount
point during mount.
Reviewed By: kmancini
Differential Revision: D26139990
fbshipit-source-id: e5097b8e90c032c8c7bdd2cd03b69695074d7874
Summary:
As I'm going through the various NFS specs, it becomes clear that variant are
widely used, and the macros to generate them is awkward and making working with
them harder than it should be. Instead writing their deserialization would be
more flexible.
While doing this, I also revamped how serialization/deserialization is done by
using a trait that contains 2 static function: serialize and deserialize, new
types are expected to specialize the XdrTrait with their own
serialization/deserialization.
Reviewed By: kmancini
Differential Revision: D26160026
fbshipit-source-id: 951bdd20620cc5715e780e99b64e15397688570d
Summary:
In NFSv3, mounting is not part of the NFS program but is done in a separate
program. This adds the basic scaffolding to reply to the NULL procedure for the
mount protocol. Later, this will be enhanced by having `eden mount` first
register a mount point to Mountd, then trigger a `mount.nfs` against localhost
where Mountd will be able to reply properly.
Similarly to PortMapUtil, I've added a small binary that allows for a "mountd"
process to be spawned. Note that since the code doesn't yet answer properly to
the mount procedure, nfusr closes the connection and retries, causing mountd to
crash due to RpcServer being unsafe on error, this will be fixed separately.
Reviewed By: chadaustin
Differential Revision: D26033504
fbshipit-source-id: 27f90d9072a93460a3a383aadde38e50801e3e87
