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>
index | next in thread | previous in thread | raw e-mail
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?). rickhome | help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1391798614.1239830.1320593648931.JavaMail.root>