On Wed, Apr 01, 2015 at 02:59:48PM -0400, Trond Myklebust wrote: > On Wed, Apr 1, 2015 at 2:51 PM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > > On Wed, Apr 01, 2015 at 11:02:17AM -0700, lyndat3@xxxxxxxxxxxxx wrote: > >> > There's no maximum sync/async ratio. You could make that ratio lower or > >> > higher by varying dd's block size, for example. > >> > > >> > The way I'd look at it, your dd of a 100MB file above is doing 3072 > >> > writes, and taking about 8*60/3072 =~ .16 seconds per write. > >> > > >> > That does sound high. Things to look at to understand why might include > >> > the round-trip ping time to the server, and the time for the server's > >> > disk to do a synchronous write. > >> > > >> > >> After comments from one of the nfs client maintainers, it turns out the slowness issue is simply one of not-quite-MIS-configuration. > >> > >> As helpfully commented here > >> > >> http://serverfault.com/questions/499174/etc-exports-mount-option/500553#500553 > >> > >> , IIUC there are two *separate* syncs to consider -- at the server, and at the client. > >> > >> 'sync' on the EXPORT, and 'async' on the MOUNT is the sane approach; That config also appears to return the performance. > >> > >> The many recommendations online to use 'sync' for data integrity are IIUC for sync on the server. > > > > Yes. This is a common source of confusion. In retrospect maybe the > > export sync/async option should have had a different name from the > > client mount option.--b. > > > > Do we still need a server 'async' export option? Who is still using > NFSv2 for any type of performance-critical work? It also bypasses commits on metadata operations. Not that that makes it a good idea, but it could still easily make a noticeable difference. --b. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
