Date: Mon, 15 Aug 2011 13:43:14 -0400 From: John Baldwin <jhb@freebsd.org> To: freebsd-fs@freebsd.org Cc: onwahe@gmail.com Subject: Re: NFS calculation of max commit size Message-ID: <201108151343.14655.jhb@freebsd.org> In-Reply-To: <1687823014.1491995.1312757266327.JavaMail.root@erie.cs.uoguelph.ca> References: <1687823014.1491995.1312757266327.JavaMail.root@erie.cs.uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sunday, August 07, 2011 6:47:46 pm Rick Macklem wrote: > A recent PR (kern/159351) noted that the following > calculation results in a divide-by-zero when > desiredvnodes < 1000. > > nmp->nm_wcommitsize = hibufspace / (desiredvnodes / 1000); > > Just fixing the divide-by-zero is easy enough, but I'm not > sure what this calculation is trying to do. Making it a fraction > of "hibufspace" makes sense (nm_wcommitsize is the maximum # of > bytes of uncommitted data in the NFS client's buffer cache blocks, > if I understand it correctly), but why divide it by > > (desiredvnodes / 1000) ?? > > Maybe thinking that fewer vnodes means sharing it with fewer > other file systems or ??? > > Anyhow, it seems to me that the formulae is bogus for small > values of desiredvnodes (for example desiredvnodes == 1500 > implies nm_wcommitsize == hibufspace, which sounds too large > to me). > > I'm thinking that putting an upper limit of 10% of hibufspace > might make sense. ie. Change the above to: > > if (desiredvnodes >= 11000) > nmp->nm_wcommitsize = hibufspace / (desiredvnodes / 1000); > else > nmp->nm_wcommitsize = hibufspace / 10; > > Anyone have comments or insight into this calculation? > > rick > ps: jhb, I hope you don't mind. I emailed you first and then > thought others might have some ideas, too. Oh no, this is fine. A broader discussion is probably warranted. I honestly don't know what the goal is. I do think it is an attempt to share with other file systems, but I'm not sure how desiredvnodes / 1000 is useful for that. It also seems that we can end up setting this woefully low as well. That is, I wonder if we need a minimum of 10% of hibufspace so that it can scale between 10% and 90% of hibufspace (but I'm not sure what you would use to pick the scaling factor sanely). To my mind what you really want to do is something like 'hibufspace / (number of active mounts)', but that will not really work correctly unless we recalculate the value on each mount and unmount operation. -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201108151343.14655.jhb>