Increase NFS_MAXRAHEAD to 32. With 32k read or write requests, that
amounts to 1 Mbyte of read-ahead, enough to cover about 10 ms latency
at gigabit Ethernet speeds. Increase the table of nfsiod kthreads
(NFS_MAXASYNCDAEMON) from 20 to 128, to match the raised value of
NFS_MAXRAHEAD. (Making the limit dynamic requires replacing the
compile-time array with a dynamic structure.)
Add a comment explaining that each read-ahead requires an I/O thread.
Wrap both parameters with an #ifdef <parameter>/#endif, to allow
hand-tuned values or (later) a kernel config-file option override.
Gone are the old kern_sysctl(), cpu_sysctl(), hw_sysctl(),
vfs_sysctl(), etc, routines, along with sysctl_int() et al. Now all
nodes are registered with the tree, and nodes can be added (or
removed) easily, and I/O to and from the tree is handled generically.
Since the nodes are registered with the tree, the mapping from name to
number (and back again) can now be discovered, instead of having to be
hard coded. Adding new nodes to the tree is likewise much simpler --
the new infrastructure handles almost all the work for simple types,
and just about anything else can be done with a small helper function.
All existing nodes are where they were before (numerically speaking),
so all existing consumers of sysctl information should notice no
difference.
PS - I'm sorry, but there's a distinct lack of documentation at the
moment. I'm working on sysctl(3/8/9) right now, and I promise to
watch out for buses.
local-loopback (lo0). As posted for review on tech-kern 2003-18-09,
with a long comment explaining (one of) the deadlock scenarios.
I've used this since shortly after 2002-09-12-, without noticing
performance degradataion or instability for non-loopback mounts.
previous error conditions.
If "(flags & (V_WAIT|V_PCATCH)) == V_WAIT" the return value is always zero.
Ignore the return value in these cases.
From Darrin B. Jewell.
file system.
The function vfs_write_suspend stops all new write operations to a file
system, allows any file system modifying system calls already in progress
to complete, then sync's the file system to disk and returns. The
function vfs_write_resume allows the suspended write operations to
complete.
From FreeBSD with slight modifications.
Approved by: Frank van der Linden <fvdl@netbsd.org>
it has a bug in the backoff calculation. so,
- clip it to 1-60 sec. (suggested by Rick Macklem)
- use a constant multiplier instead of nfs_backoff, which
is already exponential.
- move some related constant definations to nfs.h from nqnfs.h and
prefix with NFS_ instead of NQ_ because they are not nqnfs-specific.
past the end of the file. This can happen when two clients are writting to
the same file.
Close PR 21696 by myself, discussed on tech-net in 2003/05 and 2003/06.
Issue raised by Chuck Silvers (commit and truncate ops needs to be serialised)
still unadressed.
* Remove the "lwp *" argument that was added to vget(). Turns out
that nothing actually used it!
* Remove the "lwp *" arguments that were added to VFS_ROOT(), VFS_VGET(),
and VFS_FHTOVP(); all they did was pass it to vget() (which, as noted
above, didn't use it).
* Remove all of the "lwp *" arguments to internal functions that were added
just to appease the above.
be inserted into ktrace records. The general change has been to replace
"struct proc *" with "struct lwp *" in various function prototypes, pass
the lwp through and use l_proc to get the process pointer when needed.
Bump the kernel rev up to 1.6V
- for READ procedure, don't send back more bytes than requested.
- don't have doubtful assumptions on mbuf chain structure.
- rename a function (nfsm_adj -> nfs_zeropad) to avoid confusion as
the semantics of the function was changed.
retransmitted mbufs can survive even after requests themselves
finished. so, before unbusy pages, make sure that mbufs referring them
go away.
pointed by enami tsugutomo on port-mips.
while our nfsd announces MAXBSIZE as wtmax for tcp,
VOP_GETPAGES of filesystems that uses genfs_getpages can't
handle >= MAX_READ_AHEAD(16) pages at once.
therefore, depending on PAGE_SIZE of the machine and file offset of
a read request, we can't VOP_GETPAGES the range at once.
