Date: Sun, 16 Dec 2012 17:12:32 +0000 From: Chris Rees <utisoft@gmail.com> To: Konstantin Belousov <kostikbel@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: <CADLo83-c_gJd8TgJqp8JAqjSVs=JdUqEem5_vuUy_beFSeqzDQ@mail.gmail.com> In-Reply-To: <20121216044802.GX71906@kib.kiev.ua> 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> <20121216044802.GX71906@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On 16/12/2012, Konstantin Belousov <kostikbel@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@multiplay.co.uk> >> wrote: >> > ---- 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 >> >> 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. > Having investigated, this actually happens already; missing directories in /etc/exports are just warnings that can be ignored. Steven, can you provide more details on exactly what the problem is? For example, the output of showmount -e on a machine that has late filesystems in /etc/exports? Chris Scratch test: pegasus# tail -n 0 -f /var/log/messages & [1] 93579 pegasus# cat /etc/exports /nonexistent pegasus# killall -HUP mountd Dec 16 17:04:18 pegasus mountd[93469]: bad exports list line /nonexistent pegasus# showmount -e Exports list on localhost: pegasus# mkdir /nonexistent pegasus# killall -HUP mountd pegasus# showmount -e Exports list on localhost: /nonexistent Everyone pegasus# uname -a FreeBSD pegasus.bayofrum.net 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Sun Apr 29 12:29:02 BST 2012 root@pegasus.bayofrum.net:/usr/obj/usr/src/sys/PEGASUS amd64
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADLo83-c_gJd8TgJqp8JAqjSVs=JdUqEem5_vuUy_beFSeqzDQ>