Date: Tue, 9 Dec 2014 08:58:46 -0500 (EST) From: Rick Macklem <rmacklem@uoguelph.ca> To: Mark Schouten <mark@tuxis.nl> Cc: freebsd-fs@freebsd.org Subject: Re: Mountd, why not use the '-S' flag by default Message-ID: <1144091338.8206962.1418133526806.JavaMail.root@uoguelph.ca> In-Reply-To: <20141209084521.05ccb5c7@kerio.tuxis.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
Mark Schouten wrote: > Hi, >=20 > Rik Macklem wrote: > > Well, there are a couple of things: > > With "-S" all nfsd threads get suspended/resumed whenever exports > > changes. This can result in a "pause" in NFS server response and > > that might be considered a POLA violation. >=20 > IMHO, An incidental raised latency is better than input/output errors > which breaks files. >=20 > > It only works for the new NFS server and not the old one and the > > old one is still used by some. If it was the default, then the > > old and new NFS servers would have had different behaviour. > > (Again, this could be considered a POLA violation.) >=20 > Backport? Or detect the old nfsd and ignore the -S flag if it is > found? >=20 The "-S" flag will be ignored for the old server if I recall correctly. (Actually, the system call it does fails with an error, but the code doesn't mind that.) If I am wrong, then this is a bug that should be fixed. The problem is that you have differing behaviour between the two NFS servers when the flag is used. POLA stands for Principal of Least Astonishment (or something close to that) and my understanding is that this means default behaviour isn't supposed to change. (Although I wasn't the guy who committed it, I got complaints about the default # of nfsd threads changing from 4 to 8 * #cores. The default of 4 was selected in the 1980s for machines N orders of magnitude slower than the slowest hardware to-day, but some still felt the default shouldn't change.) My point, FreeBSDers take this POLA principal seriously, so I try hard not to violate it. Also, adding a new option is an easy way to document a change in the man page. > > When "-S" was introduced by me, it was done as a "stop gap", since > > I > > had thought that mountd would eventually be replaced by nfse > > (and nfse did allow exports to be updated "atomically" so the > > problem > > didn't occur). It now appears that no variant of nfse will end up > > in FreeBSD. >=20 > That's more of a reason to enable it by default, if you ask me. >=20 > > The last one is noted in the description. If, for some reason, > > mountd > > crashes during a reload, then all the nfsd threads could be stuck > > suspended. (I don't know if this occurs in practice.) >=20 > I've tested (not thoroughly) and I didn't get my client to break. > Even with errors in the exports-file, stuff kept working. Doesn't > most of NFS break without mountd anyways? >=20 > > Basically, I am a coward w.r.t. POLA and almost never change a > > default. (The one case I did change was making rsize, wsize > > default to MAX_BSIZE instead of 32K. By some strange twist of > > fate, this caused a lot of grief, since there was a bug related > > to TSO segments just under 64K for network interfaces that are > > limited to 32 transmit segments. I am still saying "disable TSO" > > to people running older FreeBSD systems because of this.;-) >=20 > Hehe. :) All I can say is that I would prefer rsize and wsize to be > bigger. But that's a different story. :) >=20 Well, MAX_BSIZE is an internal limit, but I do hope to increase MAX_BSIZE someday. I've done some testing with it set to 128K and didn't find any problems. (It's a 1 line kernel change you can try if you'd like.) 128K does seem to be desirable, since my understanding is that ZFS likes to use this size. Some will find that smaller sizes do perform better, but most should see comparable or better performance with a larger block size, from what my experience. rick > Regards, >=20 > -- > Kerio Operator in de Cloud? https://www.kerioindecloud.nl/ > Mark Schouten | Tuxis Internet Engineering > KvK:=C2=A061527076=C2=A0| http://www.tuxis.nl/ > T: 0318 200208 | info@tuxis.nl >=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1144091338.8206962.1418133526806.JavaMail.root>