tmpfs nfs exports?

Rick Macklem rmacklem at uoguelph.ca
Tue Oct 30 22:26:20 UTC 2012


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.
> 
Files don't have to be opened, since file handles are in cached NFS
vnodes. Basically, when the server reboots, the client mounts will
have to be re-done.

I think it would be nice if this behaviour of an exported tmpfs was documented,
so people don't try and use it for anything other than testing.

rick

> --
> Dan Nelson
> dnelson at allantgroup.com
> _______________________________________________
> freebsd-stable at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to
> "freebsd-stable-unsubscribe at freebsd.org"


More information about the freebsd-stable mailing list