Date: Sun, 6 Nov 2011 10:34:08 -0500 (EST) From: Rick Macklem <rmacklem@uoguelph.ca> To: Ronald Klop <ronald-freebsd8@klop.yi.org> Cc: Josh Paetzel <jpaetzel@freebsd.org>, freebsd-fs@freebsd.org, zkirsch@freebsd.org Subject: Re: [RFC] Should vfs.nfsrv.async be implemented for new NFS server? Message-ID: <1391798614.1239830.1320593648931.JavaMail.root@erie.cs.uoguelph.ca> In-Reply-To: <op.v4iz9jic8527sy@212-182-167-131.ip.telfort.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
Ronald Klop wrote: > On Sun, 06 Nov 2011 02:18:05 +0100, Rick Macklem > <rmacklem@uoguelph.ca> > wrote: > > > Hi, > > > > Josh Paetzel pointed out that vfs.nfsrv.async doesn't exist > > for the new NFS server. > > > > I don't think I had spotted this before, but when I looked I > > saw that, when vfs.nfsrv.async is set non-zero in the old server, > > it returns FILESYNC (which means the write has been committed to > > non-volatile storage) even when it hasn't actually done that. > > > > This can improve performance, but has some negative implications: > > - If the server crashes before the write is committed to > > non-volatile storage, the file modification will be lost. > > (When a server replies UNSTABLE to a write, the client holds > > onto the data in its cache and does the write again if the > > server crashes/reboots before the client does a Commit RPC > > for the file. However, a reply of FILESYNC tells the client > > it can forget about the write, because it is done.) > > - Because of the above, replying FILESYNC when the data is not > > yet committed to non-volatile (also referred to as stable) > > storage, this is a violation of RFC1813. > > Just out of curiosity. Why would lying about FILESYNC improve > performance > over UNSTABLE? The server does the same work. Only the client holds > data > longer in memory. I only see impact if the client has just a little > bit of > memory. > > Ronald. Well, I'm not sure I have an answer. Josh noted that it makes a big difference for them. Maybe he can elaborate? One additional effect is that the client in head must do a synchronous write (with FILESYNC and waiting for the RPC reply) before it can modify a non-continuous region of the same buffer with respect to the old dirty byte region. (This happens frequently during builds, done mostly by the loader, I think?) If the server replies FILESYNC, then the old dirty byte region is done (ie. no longer a dirty byte region) so the client doesn't have to do the synchronous write described above. I hope that the experimental patch I made available a few days ago, along with work jhb@ is doing will eventually fix this for the FreeBSD client, but it won't be in head anytime soon (and who knows what other clients do?). rick
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1391798614.1239830.1320593648931.JavaMail.root>