[arch-projects] [initscrupts][RFC] umount tmpfs and ramfs on shutdown
Hi guys, On shutdown we unmount/remount most filesystems. However, we make exception fro the "api" filesystems as they might still be useful and they are anyway not backed by a block device. The problem is that umount does not easily let us make exception based on mountpoints, but we have to use mounttype instead. For /sys and /proc this is ok, but /dev might be tmpfs, so we have until now avoided unmounting any tmpfs filesystems. This might be a problem if a tmpfs system is a submount of a blockdevice, as this will block the unmounting of the parent device. The attached patch (originally by Gerardo) fixes this problem when /dev is mounted as devtmpfs and keeps the old behavior if /dev is tmpfs. I made some adjustments, as noted in the commit message (Gerardo, please let me know if this looks ok with you). If someone knows of any reason not to unmount tmpfs or ramfs on shutdown, please speak up. Cheers, Tom PS Our kill and unmount logic is very fragile, and could do with a refactor, but that is a project for another day...
From d6650a257eac676b70fe2de9a679b6f223ea2673 Mon Sep 17 00:00:00 2001 From: Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> Date: Sun, 4 Jul 2010 17:16:35 -0300 Subject: [PATCH] umount tmpfs on shutdown if devtmpfs is used
This fixes FS#19783. [tomegun: some adjustments: - always umount ramfs as we never mount /dev as ramfs; and - don't umount /dev/pts as it might still be useful.] Signed-off-by: Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar> Signed-off-by: Tom Gundersen <teg@jklm.no> --- rc.shutdown | 6 +++++- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/rc.shutdown b/rc.shutdown index 7bc2243..3ee354a 100755 --- a/rc.shutdown +++ b/rc.shutdown @@ -48,7 +48,11 @@ if [[ $USELVM =~ yes|YES && -x /sbin/lvm && -d /sys/block ]]; then fi stat_busy "Unmounting Filesystems" -/bin/umount -a -r -t noramfs,notmpfs,nosysfs,noproc,nodevtmpfs -O no_netdev +if grep -q devtmpfs /proc/filesystems 2>/dev/null; then + /bin/umount -a -r -t nosysfs,noproc,nodevtmpfs,nodevpts -O no_netdev +else + /bin/umount -a -r -t notmpfs,nosysfs,noproc,nodevpts -O no_netdev +fi stat_done # Kill non-root encrypted partition mappings -- 1.7.4.4
Hi guys,
On shutdown we unmount/remount most filesystems. However, we make exception fro the "api" filesystems as they might still be useful and they are anyway not backed by a block device.
The problem is that umount does not easily let us make exception based on mountpoints, but we have to use mounttype instead. For /sys and /proc this is ok, but /dev might be tmpfs, so we have until now avoided unmounting any tmpfs filesystems.
This might be a problem if a tmpfs system is a submount of a blockdevice, as this will block the unmounting of the parent device.
The attached patch (originally by Gerardo) fixes this problem when /dev is mounted as devtmpfs and keeps the old behavior if /dev is tmpfs.
I made some adjustments, as noted in the commit message (Gerardo, please let me know if this looks ok with you).
If someone knows of any reason not to unmount tmpfs or ramfs on shutdown, please speak up. I"m happy you ask this. Because your mail subject remember me an old story about win98 (i guess), which have a big improvment from 95, by don't unloading some driver at shutdown because it was unecessary. This "improvment" speed up the shutdown. So the question, was, is
On Sat, Apr 23, 2011 at 4:32 PM, Tom Gundersen <teg@jklm.no> wrote: there a reason to unmount ramfs at shutdown? I understand the unmount chaining issue, but i don't see which case is problematic, do you have a ticket # ? 2 small points about your patch: - You should use /bin/grep and not grep, like everywhere else. - A comment before the if then else to explain why we do this will be cool. -- Sébastien Luttringer www.seblu.net
uOn Sun, Apr 24, 2011 at 9:42 PM, Seblu <seblu@seblu.net> wrote:
On Sat, Apr 23, 2011 at 4:32 PM, Tom Gundersen <teg@jklm.no> wrote:
If someone knows of any reason not to unmount tmpfs or ramfs on shutdown, please speak up.
So the question, was, is there a reason to unmount ramfs at shutdown? I understand the unmount chaining issue, but i don't see which case is problematic, do you have a ticket # ?
I assume you already saw FS#19783? If we agree that tmpfs should be unmounted (due to the chaining), then ramfs should be too (as anyone might use ramfs in place of tmpfs). We do not unmount tmpfs if /dev is mounted on tmpfs, but this can (no longer) happen on ramfs, so we always unmount it. As Thomas points out in the bug report, it might be that we don't actually need to unmount the file systems at all (only remount them ro). However, this would need to be analyzed a bit more closely. Consider this hypothetical case: a process X (some userspace filesystem daemon) cannot be killed as long as a mount Y is mounted process X has a file opened rw on mount Z (maybe a logfile on /var) a tmpfs/ramfs is a submount of Y Remounting everything ro will not work in such a scenario, so we would need to unmount Y and the tmpfs/ramfs. I don't know if this is actually happening with any setups we support, it might be worth looking into what others are doing. I have been looking at what systemd is doing and it seems quite robust. Their shutdown binary doesn't seem to work for us though.
2 small points about your patch: - You should use /bin/grep and not grep, like everywhere else. - A comment before the if then else to explain why we do this will be cool.
Good points, I'll fix this up once we have agreed on the final solution. -t
On Sun, Apr 24, 2011 at 11:55 PM, Tom Gundersen <teg@jklm.no> wrote:
uOn Sun, Apr 24, 2011 at 9:42 PM, Seblu <seblu@seblu.net> wrote:
On Sat, Apr 23, 2011 at 4:32 PM, Tom Gundersen <teg@jklm.no> wrote:
If someone knows of any reason not to unmount tmpfs or ramfs on shutdown, please speak up.
So the question, was, is there a reason to unmount ramfs at shutdown? I understand the unmount chaining issue, but i don't see which case is problematic, do you have a ticket # ?
I assume you already saw FS#19783?
If we agree that tmpfs should be unmounted (due to the chaining), then ramfs should be too (as anyone might use ramfs in place of tmpfs). We do not unmount tmpfs if /dev is mounted on tmpfs, but this can (no longer) happen on ramfs, so we always unmount it.
As Thomas points out in the bug report, it might be that we don't actually need to unmount the file systems at all (only remount them ro). However, this would need to be analyzed a bit more closely. Consider this hypothetical case:
a process X (some userspace filesystem daemon) cannot be killed as long as a mount Y is mounted process X has a file opened rw on mount Z (maybe a logfile on /var) a tmpfs/ramfs is a submount of Y
Remounting everything ro will not work in such a scenario, so we would need to unmount Y and the tmpfs/ramfs. I don't know if this is actually happening with any setups we support, it might be worth looking into what others are doing.
Tricky case. Unmouting tmpfs will not solve the case. Mount Z cannot be unmounted until X process stop and process cannot unmount until it stop to write his log. It's a bad designed mounting. I think in this case, lazy unmount offer a solution. no?
I have been looking at what systemd is doing and it seems quite robust. Their shutdown binary doesn't seem to work for us though. And what's your conclusion?
Another question why we don't unmount _netdev marked fs? Network fs should not be unmounted? -- Sébastien Luttringer www.seblu.net
On Mon, Apr 25, 2011 at 2:42 AM, Seblu <seblu@seblu.net> wrote:
On Sun, Apr 24, 2011 at 11:55 PM, Tom Gundersen <teg@jklm.no> wrote:
a process X (some userspace filesystem daemon) cannot be killed as long as a mount Y is mounted process X has a file opened rw on mount Z (maybe a logfile on /var) a tmpfs/ramfs is a submount of Y
Tricky case. Unmouting tmpfs will not solve the case. Mount Z cannot be unmounted until X process stop and process cannot unmount until it stop to write his log. It's a bad designed mounting.
Solutions would be: unmount -a (this unmounts Y and its submounts) killall (this kills X) unmount -a (this unmounts Z)
I have been looking at what systemd is doing and it seems quite robust. Their shutdown binary doesn't seem to work for us though. And what's your conclusion?
That we should look to it for inspiration (and that we sadly cannot use it...).
Another question why we don't unmount _netdev marked fs? Network fs should not be unmounted?
I don't know why this is not done, I would have thought that a forced unmount of _netdev would be needed just as unmounting tmpfs would. I think a proper solution would be to write a tool that would do something like the following: 1) remount everything ro 2) if it fail kill everything and try again 3) if it still fails unmount everything 4) if it still fails kill everything and try again (with we should loop the retries until they time out where it makes sense) It would probably make sense to do the unmounting/killing manually by parsing /proc/self/mountinfo and /proc, which would allow us to blacklist mounts (/dev, /run, /proc, /sys,...) and processes (as requested on FS). Alternatively, we could look into what it would take to be able to use the systemd shutdown binary which does something like this already (and should in principle work independently of systemd). Until someone writes something like this, I suggest we keep the commit I made (with your fixes added), as the "least wrong" solution for now. -t
participants (2)
-
Seblu
-
Tom Gundersen