On 13 March 2016 at 21:40, Ian D. Leroux <[email protected]> wrote: > 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.
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 :)
