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

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

On Fri, Mar 18, 2016, at 11:30, David Brownlee wrote:
> On 13 March 2016 at 21:40, Ian D. Leroux <idleroux%fastmail.fm@localhost> wrote:
> > 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.
>
> I definitely like the idea of it being settable. At the risk of adding
> slightly more complexity, it could have three:
> - Yes
> - No
> - Auto: If any of the current swap devices are files rather than
>   directly to devices, do the umount dance
>
> The default being auto :)

I don't think that does what you want, at least not without much more
intrusive changes to the shutdown scripts.  If there are no swap files,
on could theoretically choose not to shut down swap at all (i.e. never
run swap1_stop()) and just leave all the swap active until the system
halts.  However, as soon as you've decided to remove swap, then you have
to consider the possibility that there might be more things in
virtual memory than will fit into RAM once you've taken the swap away.
At that point it doesn't matter whether the swap is backed by a file or
a raw disk device, it's the size of its contents that matters.

If we want to automate things we either need to automate the decision of
whether to remove swap *at all*, or we need a good heuristic for "large,
dispensable consumer of virtual memory".  The old behaviour (up until a
year ago) was to assume that there wouldn't be any such consumers at
shutdown time.  The current heuristic is "all tmpfs filesystems", which
is too crude because some tmpfs filesystems are small and necessary.  My
personal preference is for manual control because I don't think there's
a universally-valid programmatically-checkable definition of
"dispensable", though Martin's suggetion of "tmpfs containing no device
nodes" might be good enough for most purposes.  Do you have any other
ideas for automatically identifying and removing consumers of too much
virtual memory?

--
IDL