Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 30 Oct 2012 10:31:42 -0500
From:      Dan Nelson <dnelson@allantgroup.com>
To:        jb <jb.1234abcd@gmail.com>
Cc:        freebsd-stable@freebsd.org
Subject:   Re: tmpfs nfs exports?
Message-ID:  <20121030153142.GA21003@dan.emsphone.com>
In-Reply-To: <loom.20121030T153828-515@post.gmane.org>
References:  <508FA008.2040503@mu.org> <loom.20121030T153828-515@post.gmane.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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.

-- 
	Dan Nelson
	dnelson@allantgroup.com



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20121030153142.GA21003>