On Sun, 13 Mar 2016 21:38:31 +0100 Martin Husemann <[email protected]> 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
