summaryrefslogtreecommitdiffstats
path: root/sys/fs/nfsclient/nfs_clrpcops.c
Commit message (Collapse)AuthorAgeFilesLines
* MFC: r297837rmacklem2016-05-061-1/+1
| | | | | | | | | | Bruce Evans reported that there was a performance regression between the old and new NFS clients. He did a good job of isolating the problem which was caused by the new NFS client not setting the post write mtime correctly. The new NFS client code was cloned from the old client, but was incorrect, because the mtime in the nfs vnode's cache wasn't yet updated. This patch fixes this problem. The patch also adds missing mutex locking.
* MFC: r291117rmacklem2015-12-051-0/+38
| | | | | | | | Revert r283330 since it broke directory caching in the client. At this time I cannot see a way to fix directory caching when it has partial blocks in the buffer cache, due to the fact that the syscall's uio_offset won't stay the same as the lblkno * NFS_DIRBLKSIZ offset.
* MFC: r285066rmacklem2015-07-271-3/+20
| | | | | | | | | | | Alex Burlyga reported a POLA violation for the new NFS client as compared to the old NFS client via email to the freebsd-fs@ mailing list. For the new client, when multiple clients attempted to create a symbolic link concurrently, more that one client would report success instead of EEXIST. This was caused by code in the new client that mapped EEXIST to OK assuming it was caused by a retried RPC request. Since the old client did not do this, the patch defaults to the old behaviour and permits the new behaviour to be enabled via a sysctl.
* MFC: r283330rmacklem2015-06-061-38/+0
| | | | | | | | | | | | The NFS client generated directory block(s) with d_fileno == 0 so that it would not return less data than requested. Since returning less directory data than requested is not a problem for FreeBSD and even UFS no longer returns directory structures with d_fileno == 0, this patch stops the client from doing this. Although entries with d_fileno == 0 should not be a problem, the man pages no longer document that these entries should be ignored, so there was a concern that these entries might be an issue in the future.
* MFC r281756:pfg2015-04-241-1/+3
| | | | | | | | nfsrpc_createv4: fix double free. Reported by: Oliver Pinter, clang static checker Obtained from: HardenedBSD (63cac77c42c0c3fc67da62f97d5ab651d52ae707) Reviewed by: rmacklem
* MFC: r264705, r264749rmacklem2014-05-061-0/+16
| | | | | | | Modify the NFSv4 client create/mkdir RPC so that it acquires post-create/mkdir directory attributes. This allows the RPC to name cache the newly created directory and reduces the lookup RPC count for applications creating a lot of directories.
* MFC: r264681rmacklem2014-05-061-4/+16
| | | | | | | Modify the NFSv4 client open/create RPC so that it acquires post-open/create directory attributes. This allows the RPC to name cache the newly created file and reduces the lookup RPC count by about 10% for software builds.
* MFC: r264672rmacklem2014-05-061-25/+32
| | | | | | | Modify the Lookup RPC for NFSv4 so that it acquires directory attributes. This allows the client to cache directory names when they are looked up, reducing the Lookup RPC count by about 40% for software builds.
* Be conservative and do not try to consume more bytes than waskib2013-01-271-1/+1
| | | | | | | | requested from the server for the read operation. Server shall not reply with too large size, but client should be resilent too. Reviewed by: rmacklem MFC after: 1 week
* Move the NFSv4.1 client patches over from projects/nfsv4.1-clientrmacklem2012-12-081-100/+1745
| | | | | | | | | | to head. I don't think the NFS client behaviour will change unless the new "minorversion=1" mount option is used. It includes basic NFSv4.1 support plus support for pNFS using the Files Layout only. All problems detecting during an NFSv4.1 Bakeathon testing event in June 2012 have been resolved in this code and it has been tested against the NFSv4.1 server available to me. Although not reviewed, I believe that kib@ has looked at it.
* Add a simple printf() based debug facility to the new nfs client.rmacklem2012-09-091-1/+2
| | | | | | | | | | Use it for a printf() that can be harmlessly generated for mmap()'d files. It will be used extensively for the NFSv4.1 client. Debugging printf()s are enabled by setting vfs.nfs.debuglevel to a non-zero value. The higher the value, the more debugging printf()s. Reviewed by: jhb MFC after: 2 weeks
* Post r230394, the Lookup RPC counts for both NFS clients increasedrmacklem2012-03-031-2/+11
| | | | | | | | | | | | | | | | | | | | | significantly. Upon investigation this was caused by name cache misses for lookups of "..". For name cache entries for non-".." directories, the cache entry serves double duty. It maps both the named directory plus ".." for the parent of the directory. As such, two ctime values (one for each of the directory and its parent) need to be saved in the name cache entry. This patch adds an entry for ctime of the parent directory to the name cache. It also adds an additional uma zone for large entries with this time value, in order to minimize memory wastage. As well, it fixes a couple of cases where the mtime of the parent directory was being saved instead of ctime for positive name cache entries. With this patch, Lookup RPC counts return to values similar to pre-r230394 kernels. Reported by: bde Discussed with: kib Reviewed by: jhb MFC after: 2 weeks
* Close a race in NFS lookup processing that could result in stale name cachejhb2012-01-201-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | entries on one client when a directory was renamed on another client. The root cause for the stale entry being trusted is that each per-vnode nfsnode structure has a single 'n_ctime' timestamp used to validate positive name cache entries. However, if there are multiple entries for a single vnode, they all share a single timestamp. To fix this, extend the name cache to allow filesystems to optionally store a timestamp value in each name cache entry. The NFS clients now fetch the timestamp associated with each name cache entry and use that to validate cache hits instead of the timestamps previously stored in the nfsnode. Another part of the fix is that the NFS clients now use timestamps from the post-op attributes of RPCs when adding name cache entries rather than pulling the timestamps out of the file's attribute cache. The latter is subject to races with other lookups updating the attribute cache concurrently. Some more details: - Add a variant of nfsm_postop_attr() to the old NFS client that can return a vattr structure with a copy of the post-op attributes. - Handle lookups of "." as a special case in the NFS clients since the name cache does not store name cache entries for ".", so we cannot get a useful timestamp. It didn't really make much sense to recheck the attributes on the the directory to validate the namecache hit for "." anyway. - ABI compat shims for the name cache routines are present in this commit so that it is safe to MFC. MFC after: 2 weeks
* opt_inet6.h was missing from some files in the new NFS subsystem.rmacklem2012-01-081-0/+2
| | | | | | | | | | The effect of this was, for clients mounted via inet6 addresses, that the DRC cache would never have a hit in the server. It also broke NFSv4 callbacks when an inet6 address was the only one available in the client. This patch fixes the above, plus deletes opt_inet6.h from a couple of files it is not needed for. MFC after: 2 weeks
* During investigation of an NFSv4 client crash reported by glebius@,rmacklem2011-12-231-6/+4
| | | | | | | | | | | | | | | | jhb@ spotted that nfscl_getstateid() might modify credentials when called from nfsrpc_read() for the case where p != NULL, whereas nfsrpc_read() only did a crdup() to get new credentials for p == NULL. This bug was introduced by r195510, since pre-r195510 nfscl_getstateid() only modified credentials for the p == NULL case. This patch modifies nfsrpc_read()/nfsrpc_write() so that they do crdup() for the p != NULL case. It is conceivable that this bug caused the crash reported by glebius@, but that will not be determined for some time, since the crash occurred after about 1month of operation. Tested by: glebius Reviewed by: jhb MFC after: 2 weeks
* Add two arguments to the nfsrpc_rellockown() function in the NFSv4rmacklem2011-11-201-6/+5
| | | | | | | | client. This does not change the client's behaviour, but prepares the code so that nfsrpc_rellockown() can be called elsewhere in a future commit. MFC after: 2 weeks
* Modify the new NFSv4 client so that it appends a file handlermacklem2011-07-031-19/+27
| | | | | | | | | | | | | to the lock_owner4 string that goes on the wire. Also, add code to do a ReleaseLockOwner Op on the lock_owner4 string before a Close. Apparently not all NFSv4 servers handle multiple instances of the same lock_owner4 string, at least not in a compatible way. This patch avoids having multiple instances, except for one unusual case, which will be fixed by a future commit. Found at the recent NFSv4 interoperability Bakeathon. Tested by: tdh at excfb.com MFC after: 2 weeks
* Fix the new NFSv4 client so that it doesn't fill the cachedrmacklem2011-06-281-2/+2
| | | | | | | | | | | | mode attribute in as 0 when doing writes. The change adds the Mode attribute plus the others except Owner and Owner_group to the list requested by the NFSv4 Write Operation. This fixed a problem where an executable file built by "cc" would get mode 0111 instead of 0755 for some NFSv4 servers. Found at the recent NFSv4 interoperability Bakeathon. Tested by: tdh at excfb.com MFC after: 2 weeks
* The new NFSv4 client was erroneously using "p" instead ofrmacklem2011-06-051-9/+9
| | | | | | | | | | "p_leader" for the "id" for POSIX byte range locking. I think this would only have affected processes created by rfork(2) with the RFTHREAD flag specified. This patch fixes that by passing the "id" down through the various functions from nfs_advlock(). MFC after: 2 weeks
* Fix the new NFS client so that it correctly sets the "must_commit"rmacklem2011-05-251-6/+9
| | | | | | | | argument for a write RPC when it succeeds for the first one and fails for a subsequent RPC within the same call to the function. This makes it compatible with the old NFS client for this case. MFC after: 2 weeks
* Modify the offset + size checks for read and write in thermacklem2011-04-201-3/+6
| | | | | | | | experimental NFS client to take care of overflows. Thanks go to dillon at apollo.backplane.com for providing the snippet of code that does this. MFC after: 2 weeks
* Fix up handling of the nfsmount structure in read and writermacklem2011-04-191-11/+11
| | | | | | | | | within the experimental NFS client. Mostly add mutex locking and use the same rsize, wsize during the operation by keeping a local copy of it. This is another change that brings it closer to the regular NFS client. MFC after: 2 weeks
* Revert r220761 since, as kib@ pointed out, the case ofrmacklem2011-04-181-5/+0
| | | | | | | | adding the check to nfsrpc_close() isn't useful. Also, the check in nfscl_getcl() must be more involved, since it needs to check before and after the acquisition of the refcnt on nfsc_lock, while the mutex that protects the client state data is held.
* Add checks for MNTK_UNMOUNTF at the beginning of threermacklem2011-04-171-0/+5
| | | | | | | | | | | | | | | | | | | functions, so that threads don't get stuck in them during a forced dismount. nfs_sync/VFS_SYNC() needs this, since it is called by dounmount() before VFS_UNMOUNT(). The nfscl_nget() case makes sure that a thread doing an VOP_OPEN() or VOP_ADVLOCK() call doesn't get blocked before attempting the RPC. Attempting RPCs don't block, since they all fail once a forced dismount is in progress. The third one at the beginning of nfsrpc_close() is done so threads don't get blocked while doing VOP_INACTIVE() as the vnodes are cleared out. With these three changes plus a change to the umount(1) command so that it doesn't do "sync()" for the forced case seem to make forced dismounts work for the experimental NFS client. MFC after: 2 weeks
* Fix readdirplus in the experimental NFS client so that itrmacklem2011-04-171-1/+22
| | | | | | | skips over ".." to avoid a LOR race with nfs_lookup(). This fix is analagous to r138256 in the regular NFS client. MFC after: 2 weeks
* Add a lktype flags argument to nfscl_nget() and ncl_nget() in thermacklem2011-04-161-1/+1
| | | | | | | experimental NFS client so that its nfs_lookup() function can use cn_lkflags in a manner analagous to the regular NFS client. MFC after: 2 weeks
* Fix the experimental NFSv4 server so that it uses VOP_PATHCONF()rmacklem2011-04-141-1/+1
| | | | | | | | | to determine if a file system supports NFSv4 ACLs. Since VOP_PATHCONF() must be called with a locked vnode, the function is called before nfsvno_fillattr() and the result is passed in as an extra argument. MFC after: 2 weeks
* Modify the experimental NFSv4 server so that it handlesrmacklem2011-04-141-2/+2
| | | | | | | | | | | | | crossing of server mount points properly. The functions nfsvno_fillattr() and nfsv4_fillattr() were modified to take the extra arguments that are the mount point, a flag to indicate that it is a file system root and the mounted on fileno. The mount point argument needs to be busy when nfsvno_fillattr() is called, since the vp argument is not locked. Reviewed by: kib MFC after: 2 weeks
* This patch fixes the Experimental NFS client to properly deal with 32 bit or 64zack2011-03-301-3/+3
| | | | | | | | | | | | bit fileid's in NFSv2 and NFSv3. Without this fix, invalid casting (and sign extension) was creating problems for any fileid greater than 2^31. We discovered this because we have test clusters with more than 2 billion allocated files and 64-bit ino_t's (and friend structures). Reviewed by: rmacklem Approved by: zml (mentor) MFC after: 2 weeks
* Store the full timestamp when caching timestamps of files andjhb2010-09-071-2/+1
| | | | | | | | | | directories for purposes of validating name cache entries. This closes races where two updates to a file or directory within the same second could result in stale entries in the name cache. While here, remove the 'n_expiry' field as it is no longer used. Reviewed by: rmacklem MFC after: 1 week
* For the experimental NFSv4 client, make sure that attributes thatrmacklem2010-07-131-0/+14
| | | | | | | | predate the issue of a delegation are not cached once the delegation is held. This is necessary, since cached attributes remain valid while the delegation is held. MFC after: 2 weeks
* In NFS clients, instead of inconsistently using #ifdefkib2010-06-131-12/+7
| | | | | | | | DIAGNOSTIC and #ifndef DIAGNOSTIC for debug assertions, prefer KASSERT(). Also change one #ifdef DIAGNOSTIC in the new nfs server. Submitted by: Mikolaj Golub <to.my.trociny gmail com> MFC after: 2 weeks
* Delete a diagnostic statement that is no longer useful fromrmacklem2010-04-281-4/+0
| | | | | | the experimental NFS client. MFC after: 1 week
* An NFSv4 server will reply NFSERR_GRACE for non-recovery RPCsrmacklem2010-04-241-12/+14
| | | | | | | | | | | | during the grace period after startup. This grace period must be at least the lease duration, which is typically 1-2 minutes. It seems prudent for the experimental NFS client to wait a few seconds before retrying such an RPC, so that the server isn't flooded with non-recovery RPCs during recovery. This patch adds an argument to nfs_catnap() to implement a 5 second delay for this case. MFC after: 1 week
* When the experimental NFS client is handling an NFSv4 server rebootrmacklem2010-04-221-4/+12
| | | | | | | | | | | | with delegations enabled, the recovery could fail if the renew thread is trying to return a delegation, since it will not do the recovery. This patch fixes the above by having nfscl_recalldeleg() fail with the I/O operations returning EIO, so that they will be attempted later. Most of the patch consists of adding an argument to various functions to indicate the delegation recall case where this needs to be done. MFC after: 1 week
* The experimental NFS client was not filling in recovery credentialsrmacklem2010-04-151-1/+7
| | | | | | | | | | | for opens done locally in the client when a delegation for the file was held. This could cause the client to crash in crsetgroups() when recovering from a server crash/reboot. This patch fills in the recovery credentials for this case, in order to avoid the client crash. Also, add KASSERT()s to the credential copy functions, to catch any other cases where the credentials aren't filled in correctly. MFC after: 1 week
* Fix the experimental NFS client so that it can create Unixrmacklem2009-12-311-4/+9
| | | | | | | | domain sockets on an NFSv4 mount point. It was generating incorrect XDR in the request for this case. Tested by: infofarmer MFC after: 2 weeks
* Remove unneeded ifdefs.trasz2009-12-031-10/+0
| | | | Reviewed by: rmacklem
* When vfs.newnfs.callback_addr is set to an IPv4 address, thermacklem2009-07-221-1/+1
| | | | | | | | experimental NFSv4 client might try and use it as an IPv6 address, breaking callbacks. The fix simply initializes the isinet6 variable for this case. Approved by: re (kensmith), kib (mentor)
* Since the nfscl_getclose() function both decremented open counts and,rmacklem2009-07-091-83/+79
| | | | | | | | | | | | | optionally, created a separate list of NFSv4 opens to be closed, it was possible for the associated OpenOwner to be free'd before the Open was closed. The problem was that the Open was taken off the OpenOwner list before the Close RPC was done and OpenOwners can be free'd once the list is empty. This patch separates out the case of doing the Close RPC into a separate function called nfscl_doclose() and simplifies nfsrpc_doclose() so that it closes a single open instead of a list of them. This avoids removing the Open from the OpenOwner list before doing the Close RPC. Approved by: re (kensmith), kib (mentor)
* Change the experimental NFSv4 client so that it does not dormacklem2009-05-181-4/+7
| | | | | | | | | the NFSv4 Close operations until ncl_inactive(). This is necessary so that the Open StateIDs are available for doing I/O on mmap'd files after VOP_CLOSE(). I also changed some indentation for the nfscl_getclose() function. Approved by: kib (mentor)
* Add the experimental nfs subtree to the kernel, that includesrmacklem2009-05-041-0/+4173
support for NFSv4 as well as NFSv2 and 3. It lives in 3 subdirs under sys/fs: nfs - functions that are common to the client and server nfsclient - a mutation of sys/nfsclient that call generic functions to do RPCs and handle state. As such, it retains the buffer cache handling characteristics and vnode semantics that are found in sys/nfsclient, for the most part. nfsserver - the server. It includes a DRC designed specifically for NFSv4, that is used instead of the generic DRC in sys/rpc. The build glue will be checked in later, so at this point, it consists of 3 new subdirs that should not affect kernel building. Approved by: kib (mentor)
OpenPOWER on IntegriCloud