Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 16 Dec 2012 06:48:02 +0200
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        Chris Rees <utisoft@gmail.com>
Cc:        "freebsd-rc@freebsd.org" <rc@freebsd.org>, Steven Hartland <killing@multiplay.co.uk>
Subject:   Re: Adding dependency on mountlate to mountd
Message-ID:  <20121216044802.GX71906@kib.kiev.ua>
In-Reply-To: <CADLo838xeXMdcaW1kB0ZdUzkUGeAVuxUJ0sF_GHeUa8yFsNGuA@mail.gmail.com>
References:  <6A58ADA440454E5889DBA6D2D9C56180@multiplay.co.uk> <CAF6rxg=UoSONKXLub7RFTK6Hi7oXRgJ0c7gvhOXW53sa2h964Q@mail.gmail.com> <20121215091424.GS71906@kib.kiev.ua> <CADLo839yEpvMC_BhBzmJ2heNtdUtNHCQymqho4AkJP0hVfdr5g@mail.gmail.com> <1F93E0D525B946B88405EC4203385E0A@multiplay.co.uk> <CADLo838xeXMdcaW1kB0ZdUzkUGeAVuxUJ0sF_GHeUa8yFsNGuA@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help

--Ios1FkwfffwWp4ib
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Dec 15, 2012 at 10:12:00PM +0000, Chris Rees wrote:
> On 15 December 2012 20:09, Steven Hartland <killing@multiplay.co.uk> wrot=
e:
> > ---- Original Message -----
> >>
> >> From: Chris Rees On 15 Dec 2012 09:14, "Konstantin Belousov"
> >> <kostikbel@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 t=
his
> >> 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.


>=20
> 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.

--Ios1FkwfffwWp4ib
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (FreeBSD)

iQIcBAEBAgAGBQJQzVKBAAoJEJDCuSvBvK1Bv1EP/jctzYCNVe1/q4LkaX+mMY9G
i9SA/RIeG41fGG5IovDkYk4lUVzuOrij8DGL+yoY+IX+6UcmflgjaZUChDosQvXg
exF8yx/+HuSa7hjfCqBu2HDG7+6KRs4efOxYfHRE/IIk+joHiZ4iDpk7UyWA5hkk
H7+0WOcmm+n/y+Nzsm9hzsOZkPgedD8cdN103ZDy/PV4ulsmjYE5SjO9PJSIhPeT
67gl0rHWIgi0LuuYhpqF1z1FG2a/t2hqUog+AsyXxXZsY0Fek1g2nL9OVnr7oMa+
oXz2A/SCi8XRQc6F2ND07WS0Nr0dbZ0G0Xeaw4W1saFoVg5E2xiRawlgwofYUEE3
G/yG3Y2yDc7J3gAEKcdnCvrhS4vQcla5tRBBtHggUSOKrJBLneOm+xKnH2nYB0Ry
JeluAGJ9iuehy3gEOzPyHj91ibgbD2qCl4dtygg1CadZARzhLAqCKHUrUUAxivgo
ZYr2HS6H1cP6l8ZiiQlCKKwKkfvfEqJKGBD9kAsY0m1v8Oo7YVZ1yx6MrTsvcmds
Y0T/zprL0a96spPqvf57QwPwuEJZDKC5U6yAQgqqgVTAOBWZstKP8N9zaB283UhQ
aVyYQQxIBl0oKRSLzobVTBfDjG05bmo8z/QBjByhZ1dxrge+ZFOsm8jiaxEUCKec
FEuie9VNEx/kRf5VUbd8
=U5nY
-----END PGP SIGNATURE-----

--Ios1FkwfffwWp4ib--



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