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