We can not have a static rpc->inbuf buffer since that will no longer guarantee
that the received buffer is valid for the duration of callbacks.
One of the problems is that if we issue new (sync) RPCs from within a
callback, that will overwrite and invalidate the receive buffer that
we passed to the callback.
Revert "init: do not leak rpc->inbuf"
This reverts commit f7bc4c8bb1.
Revert "socket: we have to use memmove in rpc_read_from_socket"
This reverts commit 24429e95b8.
Revert "socket: make rpc->inbuf static and simplify receive logic"
This reverts commit 7000a0aa04.
only logging to stderr is supported at the moment. Per default
there is no output. Its possible to set the log level via
debug url parameter.
Example:
nfs-ls nfs://127.0.0.1/export?debug=2
Signed-off-by: Peter Lieven <pl@kamp.de>
the write limit of libnfs has been 1M since a long time.
Restrict rtmax and wrmax to 1M and error out otherwise.
Limit the PDU size when reading from socket to rule out
malicious servers forcing us to allocate a lot of memory.
Signed-off-by: Peter Lieven <pl@kamp.de>
Update the configure to add some sanity -W arguments.
A good start is probably :
-Wall -Werror -Wshadow -Wno-write-strings -Wstrict-prototypes
-Wpointer-arith -Wcast-align -Wno-strict-aliasing
Fixup the paces in the code that triggers.
(one of which is readahead code which is perhaps broken?)
Signed-off-by: Ronnie Sahlberg <ronniesahlberg@gmail.com>
This patch add support for an internal readahead machanism. The maximum readahead
size can be specified via URL parameter readahead. This should significantly
speed up small sequential reads.
Signed-off-by: Peter Lieven <pl@kamp.de>
Use the macro when removing the pdus in the wait list from the queues.
Also make sure to remove them from the right queue, from waitqueue and not
the outqueue for PDUs we have already sent out.
Signed-off-by: Ronnie Sahlberg <ronniesahlberg@gmail.com>
NFS servers can respond to requests in any order, and they do. In our
tests there is also some clustering to the responses; it could be
because eg. requests are served synchronously if the data is in the cache.
Introduce a hash table so that we are able to find the pdu quickly in
all cases, assuming random distribution of the responses.
When making many concurrent requests (as is likely in any performance
criticial application), the use of SLIST_REMOVE and SLIST_ADD_END are
a severe bottleneck because of their linear search.
I considered using a double-linked list but it was unnecessary to
allocate the additional memory for each list entry.
Instead, continue to use a single-linked list but retain:
* a pointer to the end of the list; and
* a pointer to the previous entry during a linear search.
The former would makes append operations O(1) time, and the latter
does the same for removal. We can do this because removal only happens
within the linear search, and there is no random access to the queue.
This allows to connect with an alternate uid or gid than that
of the current user.
Example:
examples/nfs-ls nfs://10.0.0.1/export?uid=1000&gid=33
Signed-off-by: Peter Lieven <pl@kamp.de>
This allows indirect support for a configurable connect timeout.
Linux uses a exponential backoff for SYN retries starting
with 1 second.
This means for a value n for TCP_SYNCNT, the connect will
effectively timeout after 2^(n+1)-1 seconds.
Example:
examples/nfs-ls nfs://10.0.0.1/export?tcp-syncnt=1
Signed-off-by: Peter Lieven <pl@kamp.de>
This helps for users which rapidly fork a lot of processes that then
immediately create a new context (I am looking at you dbench)
to awoid having lots of processes starting and using overlapping xid values.
This patch switches libnfs over to use precompiled rpcgen files
and using ZDR. ZDR is a trivial reimplementation of XDR that is built in
into libnfs.
This removes the dependencies of rpc/xdr completely and allow us to build on any
system, even systems where rpcgen and librpc/libxdr are not generally available.