On Sun, Apr 24, 2011 at 11:55 PM, Tom Gundersen <[email protected]> wrote: > uOn Sun, Apr 24, 2011 at 9:42 PM, Seblu <[email protected]> wrote: >> On Sat, Apr 23, 2011 at 4:32 PM, Tom Gundersen <[email protected]> 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
