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

[David Brownlee <abs%absd.org@localhost>]

On 13 March 2016 at 21:40, Ian D. Leroux <idleroux%fastmail.fm@localhost> wrote:
> 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.

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 :)