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>
Always pass a fattr3 structure to the callbacks for the internal function
to perform recursive lookups : nfs_lookuppath_async().
This will allow us to access for example the mtime for an object before we
start performing any expensive functions.
Signed-off-by: Ronnie Sahlberg <ronniesahlberg@gmail.com>
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>
commit 1c1e09a completely broke connects for non broadcast
traffic since it forgot to copy the server address into
the socket_storage struct.
Signed-off-by: Peter Lieven <pl@kamp.de>
Add a prebuilt manpage for nfs-ls and change the makefiles to not build the
manpage by default. This is because the manpages change rarely and this removes
the need for an internet connection when building the library.
(previously building the library required downloading a template from
sourceforge)
Update the README and mention that you now need to manually rebuild the
manpages if the manpage sources change.
Signed-off-by: Ronnie Sahlberg <ronniesahlberg@gmail.com>
Since the interface is modelled after the libc calls we should try to match
their behaviour to avoid unpleasant surprises:
* read / write (sync and async flavours) update the file position
* pread / pwrite (sync and async flavours) do not update the file position
.
Signed-off-by: Arne Redlich <arne.redlich@googlemail.com>
Previously nfs_read and nfs_write used to use nfs_pread and nfs_pwrite respectively.
In preparation of getting the file position handling right this has to be detangled.
Signed-off-by: Arne Redlich <arne.redlich@googlemail.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.
Fixes a bug where the next pointer was not being explicitly set. We
were ok much of the time due to zero-filled memory, and also we need
this if the same pdu is re-queued.
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.
Otherwise end up with a null string which is not permitted (RFC 1813, 3.2;
the code checks for it right after the now fixed nullification of "/").
Signed-off-by: Arne Redlich <arne.redlich@googlemail.com>
Ronnie Sahlberg