Date: Tue, 30 Oct 2012 10:07:55 -0700 From: Alfred Perlstein <bright@mu.org> To: freebsd-stable@freebsd.org Subject: Re: tmpfs nfs exports? Message-ID: <5090096B.5070405@mu.org> In-Reply-To: <20121030153142.GA21003@dan.emsphone.com> References: <508FA008.2040503@mu.org> <loom.20121030T153828-515@post.gmane.org> <20121030153142.GA21003@dan.emsphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/30/12 8:31 AM, Dan Nelson wrote: > In the last episode (Oct 30), jb said: >> Alfred Perlstein <bright <at> mu.org> writes: >>> Hey folks, any reason why not to include the following patch in 9.1? It >>> would be nice to have tmpfs be exportable. >>> >>> I'm good to commit it, I can also wait until post 9.1. >>> ... >> How do you identify tmpfs ? With fsid ? >> >> Since nfs server is stateless, are these exports identical ? >> export /tmp, reboot, export /tmp >> >> What about /tmp on tmpfs ? >> export /tmp, reboot, export /tmp > I wanted to do the exact same thing a few years ago. I patched mdmfs and > the startup scripts to allow for an fsid value to be passed to mdmfs on > every reboot. That works for the filesystem itself, but then you have to > contend with the random NFS generation number on every inode. I decided it > wasn't worth the trouble at that point. > > If you really want an exportable /tmp, just live with the fact that you'll > get ESTALE errors on all clients when you reboot the server. Maybe giving > the root inode a constant generation number is all that's needed, since I > suppose most clients that have mounted the server don't actually have any > open filehandles. > Ah, that is troublesome. This fix is really just for benchmarking nfs without hitting disk and other very temporary measures. It would be nice to make root inode predictable in some manner. -Alfred
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5090096B.5070405>