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

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

On Sun, 13 Mar 2016 21:38:31 +0100 Martin Husemann <martin%duskware.de@localhost>
wrote:
> This is all good for "planned" instances of /dev on tmpfs, but since
> this is also done automagically by init when /dev/console has gone
> missing, I wonder if it would be better to just check for /dev as
> mountpoint explicitly and skip that tmpfs.
>
> Or run a find for device nodes (which should be very quick) on each
> tmpfs before unmounting it?
> 
> But maybe the manual solution is the best (less magic).

I chose a positive list of filesystems to unmount rather than a
negative list of filesystems to skip mostly because it makes the
implementation simpler (no need to grep through mount's output
filtering out the skipped filesystems).  As you say, it's nice that
it's not magic and doesn't hardcode any filesystem names
into /etc/rc.d/swap1 (where I don't think they belong).  It's also
general: it's not obvious to me that the /dev issue is the only reason
you might ever want to control or prevent the unmounting of filesystems
by the swap1 script, and this mechanism gives you control no matter the
motivation.

I think there's a reasonable discussion to be had about defaults
though.  I defaulted to "ALL" to preserve the current behaviour, on the
assumption that /dev-on-tmpfs is a non-standard choice made by users
experienced enough to use non-default rc.conf settings when it breaks.
If /dev/console can just go missing however (does that happen?), so
that /dev-on-tmpfs can happen to unsuspecting beginners, then I'd much
rather default to the empty list (i.e. don't unmount anything by
default).  That should still work fine for a standard installation,
where only /var/shm is on tmpfs, but would place the burden of
non-default settings on those users who mount and populate tmpfs
filesystems bigger than RAM.

Since the unmount-at-swapoff logic was first added less than a year
ago, I'm guessing that the problem it was meant to fix isn't common.
Would it be acceptable to make unmounting-at-swapoff an opt-in rather
than opt-out choice?  That would smell better to me (in that swap1
doesn't really have any logical business messing with filesystem
mounts), but I don't have a good feel for the relative prevalence of
the two problems in common setups and so I can't properly judge what is
likely to cause the least surprise.

--
IDL