Adding dependency on mountlate to mountd

[Chris Rees]

On 16 Dec 2012 04:48, "Konstantin Belousov" <kostikbel at gmail.com> wrote:
>
> On Sat, Dec 15, 2012 at 10:12:00PM +0000, Chris Rees wrote:
> > On 15 December 2012 20:09, Steven Hartland <killing at multiplay.co.uk>
wrote:
> > > ---- Original Message -----
> > >>
> > >> From: Chris Rees On 15 Dec 2012 09:14, "Konstantin Belousov"
> > >> <kostikbel at gmail.com> wrote:
> > >> > It cannot be fine. It breaks local NFS mounts.
> > >>
> > >> Given that we can't have both, but we can have nullfs and thus solve
this
> > >> problem.
> > >> Is there something that local NFS mounts can do that nullfs won't?
> > >
> > >
> > > Using local NFS mounts seems a bit of strange thing to do, whats the
> > > reason for the requirement for these?
> > >
> > > Wouldnt nullfs mounts replace this requirement and perform better?
> No, because there are different use cases. What was useful for me was
> the case of migrating services, when the client machine happens to be
> the same as the export one. Ability to do loopback nfs mounts removes
> the need for non-trivial reconfiguration.
>
>
> >
> > Here's an idea, how about in the mountlate script, we pass SIGHUP to
> > mountd at the end (or simply restart it, but that'd be slower)?  This
> > would cover your use case and Kostik's example too.
>
> The mount(8) already sends SIGHUP to mountd, it is even noted in the
> man. Sometimes it results in the quite puzzling behaviour, see e.g.
> r172577, which in fact was blamed on a bug in our TCP stack.
>
> The only case which could not be covered yet is the unability to specify
> export points in the exports(5) which only appear after some late
> mounts are performed. I think that if you really concerned with this, a
> flag to the mountd(8) might be added which allows the daemon to ignore
> non-existing export directories.

That's a great idea.

Steven, would you accept that as a solution?

Chris