Improve the queuing algorithms used by NFS' asynchronous i/o. The
existing mechanism uses a global queue for some buffers and the
vp->b_dirtyblkhd queue for others. This turns sequential writes into
randomly ordered writes to the server, affecting both read and write
performance. The existing mechanism also copes badly with hung
servers, tending to block accesses to other servers when all the iods
are waiting for a hung server.
The new mechanism uses a queue for each mount point. All asynchronous
i/o goes through this queue which preserves the ordering of requests.
A simple mechanism ensures that the iods are shared out fairly between
active mount points.
Reviewed/integrated/approved by Frank van der Linden <fvdl@netbsd.org>
struct member cn_nameptr 'const', since they should never be used to
modify the path name. (Only the pathname buffer, cn_pnbuf, should be
modified.) Propagate the const poisoning to code that uses the namei
and componentname structs.
* Make 2nd and 3rd args timespecs, not timevals.
* Consistently pass a Boolean as the 4th arg (except in LFS).
Also, fix ffs_update() and lfs_update() to actually change the nsec fields.
* Change the argument names to vop_link so they actually make sense.
* Implement vop_link and vop_symlink for all file systems, so they do proper
cleanup.
* Require the file system to decide whether or not linking and unlinking of
directories is allowed, and disable it for all current file systems.
each entry, and read them out in nfs_readdir().
Caveat: our current caching method for directory blocks uses the
server offset of the first directory entry as an identifier, so a
Linux emulation getdirentries() will wind up retrieving one block from
the NFS server for each directory entry, unnecessarily thrashing the
cache. The situation isn't as bad for other emulations.
Instead of getblk(), we need to write a routine to scan each cache
block associated with vp to find a cookie that matches at some
directory entry. Some later time.
(1) it's unnecessary
(2) it causes machines to hang (yup!)
(3) it'd be gone in a few days anyway (it'd been yanked out
of 4.4-Lite by macklem long ago)
It was only there because macklem couldn't originally decide if things
should be locked, or not...
