FreeBSD source tree https://cgit-dev.freebsd.org/src/atom?h=upstream%2F10.1.0 2013-12-30T21:17:20Z 2013-12-30T21:17:20Z Rick Macklem rmacklem@FreeBSD.org 2013-12-30T21:17:20Z urn:sha1:a2e3a3e3ebc4c128859ab940b3e57532a4bddbca For software builds, the NFS client does many small synchronous (with FILE_SYNC) writes because non-contiguous byte ranges in the same buffer cache block are being written. This patch adds a new mount option "noncontigwr" which allows the non-contiguous byte ranges to be combined, with the dirty byte range becoming the superset of the bytes that are dirty, if the file has not been file locked. This reduces the number of writes significantly for software builds. The only case where this change might break existing applications is where an application is writing non-overlapping byte ranges within the same buffer cache block of a file from multiple clients concurrently. Since such an application would normally do file locking on the file, avoiding the byte range merge for files that have been file locked should be sufficient for most (maybe all?) cases. 2013-07-04T00:54:23Z Rick Macklem rmacklem@FreeBSD.org 2013-07-04T00:54:23Z urn:sha1:913df8fd72b732f1a8c64e5ddbd4de73c7be5d78 would sometimes result in a corrupted file was reported via email. This problem appears to have been caused by r251719 (reverting r251719 fixed the problem). Although I have not been able to reproduce this problem, I suspect it is caused by another thread increasing np->n_size after the mtx_unlock(&np->n_mtx) but before the vnode_pager_setsize() call. Since the np->n_mtx mutex serializes updates to np->n_size, doing the vnode_pager_setsize() with the mutex locked appears to avoid the problem. Unfortunately, vnode_pager_setsize() where the new size is smaller, cannot be called with a mutex held. This patch returns the semantics to be close to pre-r251719 such that the call to the vnode_pager_setsize() is only delayed until after the mutex is unlocked when np->n_size is shrinking. Since the file is growing when being written, I believe this will fix the corruption. Reported by: David G. Lawrence (dg@dglawrence.com) Tested by: David G. Lawrence (pending, to happen soon) Reviewed by: kib MFC after: 1 week 2013-07-01T21:16:19Z Rick Macklem rmacklem@FreeBSD.org 2013-07-01T21:16:19Z urn:sha1:28be5427f11582d9c643dc872ef45325bd96e0e5 will crash when doing a large write, since m_get2() would return NULL. This patch fixes the problem, since nfsm_uiotombuf() will allocate additional mbufs, as required. Reported by: sbruno Tested by: sbruno Discussed with: glebius 2013-05-31T00:43:41Z Jeff Roberson jeff@FreeBSD.org 2013-05-31T00:43:41Z urn:sha1:22a722605d723aab89d510c7a77d6508fb995785 - Use a shared bufobj lock in getblk() and inmem(). - Convert softdep's lk to rwlock to match the bufobj lock. - Move INFREECNT to b_flags and protect it with the buf lock. - Remove unnecessary locking around bremfree() and BKGRDINPROG. Sponsored by: EMC / Isilon Storage Division Discussed with: mckusick, kib, mdf 2013-05-29T00:32:49Z Rick Macklem rmacklem@FreeBSD.org 2013-05-29T00:32:49Z urn:sha1:456219935079760ca57c79870450d04f296e8e0f old NFS client to avoid the panic reported in the PR by doing the vnode_pager_setsize() call after unlocking the mutex. PR: 177335 MFC after: 2 weeks 2013-04-18T23:20:16Z Rick Macklem rmacklem@FreeBSD.org 2013-04-18T23:20:16Z urn:sha1:64a0e848abbc491831a2969e72ecfb6a0ae9716c buffer for the last vnode on the mount back to the server, it returns. At that point, the code continues with the unmount, including freeing up the nfs specific part of the mount structure. It is possible that an nfsiod thread will try to check for an empty I/O queue in the nfs specific part of the mount structure after it has been free'd by the unmount. This patch avoids this problem by setting the iodmount entries for the mount back to NULL while holding the mutex in the unmount and checking the appropriate entry is non-NULL after acquiring the mutex in the nfsiod thread. Reported and tested by: pho Reviewed by: kib MFC after: 2 weeks 2013-04-18T13:09:04Z Rick Macklem rmacklem@FreeBSD.org 2013-04-18T13:09:04Z urn:sha1:175b3f31d328545a5bca42b0f6ac6de344e0eb4a option. This can occur when an nfsiod thread that already holds a buffer lock attempts to acquire a vnode lock on an entry in the directory (a LOR) when another thread holding the vnode lock is waiting on an nfsiod thread. This patch avoids the deadlock by disabling readahead for this case, so the nfsiod threads never do readdirplus. Since readaheads for directories need the directory offset cookie from the previous read, they cannot normally happen in parallel. As such, testing by jhb@ and myself didn't find any performance degredation when this patch is applied. If there is a case where this results in a significant performance degradation, mounting without the "rdirplus" option can be done to re-enable readahead for directories. Reported and tested by: jhb Reviewed by: jhb MFC after: 2 weeks 2013-03-19T13:06:11Z Ed Maste emaste@FreeBSD.org 2013-03-19T13:06:11Z urn:sha1:96ecfd9813e28e4063dda8fe1e7377adf7f25c8d In common configurations biosize is a power of two, but is not required to be so. Thanks to markj@ for spotting an additional case beyond my original patch. Reviewed by: rmacklem@ 2013-03-13T21:06:03Z John Baldwin jhb@FreeBSD.org 2013-03-13T21:06:03Z urn:sha1:3b14c753ff70b86b5ca129bfb62b516ed53054a7 implemented via VFCF_SBDRY rather than passing PBDRY to individual sleep calls. 2013-03-12T13:42:47Z Gleb Smirnoff glebius@FreeBSD.org 2013-03-12T13:42:47Z urn:sha1:41a7572b26da5acade4565f8cf943b13ac6fedb5 and that can drive someone crazy. While m_get2() is young and not documented yet, change its order of arguments to match m_getm2(). Sorry for churn, but better now than later.