Subject: Re: Exports list management, take 3
To: YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp>
From: Julio M. Merino Vidal <jmmv84@gmail.com>
List: tech-kern
Date: 09/20/2005 12:59:34
On 9/20/05, YAMAMOTO Takashi <yamt@mwd.biglobe.ne.jp> wrote:
> > > - don't hardcode AF_MAX in mountd_exports_list.
> > >   i don't think AF_MAX is appropriate.
> >
> > OK.  Should I define a new constant or maybe try to handle dynamically
> > sized structures?  (Dunno how to do the latter yet.)
>=20
> have a pointer and do another copyin?

Oh, true!  I was thinking about returning the exports list to userland,
and I didn't remember I had removed that functionality from the patch
(it wasn't available before and it's rather complex to implement).  This
is the part where a dynamically sized structure may get trickier, isn't it?

> > > - i'm not sure if vfsfeature is a good idea.
> > >   are there any possible users other than nfs?
> >
> > I think it will be useful if we move more stuff out of specific file
> > systems into kernel generic parts.  I don't know yet if this will be
> > possible at all, but if this is not appropriate...  do you see any othe=
r
> > clean way to initialize the NFS stuff without having to put an '#ifdef
> > NFSSERVER' in the system code?  That will do the trick, but it is
> > kind of ugly and doesn't separate the NFS code from the VFS one.
> > That was the point of this vfsfeatures thing.
>=20
> can't you do the initialization on the first request?

Hmm... that could work.  But what about the cleanup routine called
during unmount?

> > > - what's the point of del_exports in send_umntall?
> >
> > send_umntall is the SIGTERM signal handler.  Shouldn't mountd(8)
> > unexport all file systems on exit?  If not, why not?
>=20
> i'm not sure if it should.
> it makes stopping mountd on a running server somewhat fragile.
> on the other hand, i can't think of any benefits of it.

The problem is that after exiting mountd, you are left with several
file systems exported.  I find this a bit wired.  The benefit I can
think of (and I'm not sure it really is one) is in the case you were under
attack, you'd close access to file systems by stopping mountd.

Or even if not under attack, how can you deexport a file system
without rebooting, if you've already started mountd?  Ok, you can
nuke /etc/exports and reload the configuration file... but that's a bit
ugly.

> anyway, as it isn't related to the rest of the patch, it should be
> omitted at this point, IMO.

Agreed.

Thanks,

--=20
Julio M. Merino Vidal <jmmv84@gmail.com>
http://www.livejournal.com/users/jmmv/
The NetBSD Project - http://www.NetBSD.org/