Re: [PATCH] control which tmpfs get unmounted at swapoff

["Ian D. Leroux" <idleroux%fastmail.fm@localhost>]

On Sat, 19 Mar 2016 08:29:08 +0000 (GMT) Iain Hibbert
<plunky%ogmig.net@localhost> wrote:

> On Fri, 18 Mar 2016, Ian D. Leroux wrote:
> 
> > Here's slightly better compromise, that does the right thing by
> > default in more cases.  The rc.conf variable "swapoff_umount" (name
> > changed for clarity) can be either
> > - an explicit list of zero or more tmpfs filesystems to umount
> > before removing swap devices, or
> > - "auto", in which case all tmpfs mounts containing no device nodes
> > are removed, as you suggested at the beginning of the week.
> 
> I'm uneasy about a 'magic' value, which could be problematic (sorry,
> did you have a filesystem named auto?).. is it a problem to have
> 
> 	not set ->	auto behaviour
> 	set ->		unmount the file systems listed, if any
> 
> ?

In practise "auto" doesn't conflict with any valid setting because the
correct setting if you have a tmpfs mounted on a directory named auto
is "/auto".  I should in any case document that the mount points are to
be specified as absolute paths, since we don't want to be relying on
the current working directory of the shell used to run rc.d scripts.

If we want to avoid magic values completely, we can split the
configuration into two settings:
  swapoff_umount (auto, manual, no)
  swapoff_umount_list (only used if $swapoff_umount=manual)
Perhaps that would be better (more explicit).  What say you?

Still, having taken an embarrassingly long time to remember the
distinction between unset and empty and hence to realize that your
proposal still allows the empty variable as a "don't unmount anything"
setting, I have to admit that it's the tidiest proposal yet.  If we do
go that route, I'll have to come up with a better variable name, since
it is not at all intuitive that "swapoff_umount" being unset will lead
to things being unmounted.

Another point that occurred to me last night is that my current script
doesn't handle mount points whose paths contain spaces.  Are the rc.d
scripts generally robust against space-containing filesystem names?  If
so I should spend some time figuring out the quoting, and the list of
filesystems to unmount will have to use a different separator.  What's
the conventional preference here?

--
IDL