From mboxrd@z Thu Jan 1 00:00:00 1970 From: Elladan Subject: Re: [PATCH] [Request for inclusion] Filesystem in Userspace Date: Thu, 18 Nov 2004 12:16:13 -0800 Message-ID: <20041118201613.GA30308@eskimo.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Miklos Szeredi , hbryan@us.ibm.com, akpm@osdl.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, pavel@ucw.cz Return-path: Received: from ultra7.eskimo.com ([204.122.16.70]:32264 "EHLO ultra7.eskimo.com") by vger.kernel.org with ESMTP id S262968AbUKRUTO (ORCPT ); Thu, 18 Nov 2004 15:19:14 -0500 To: Linus Torvalds Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Thu, Nov 18, 2004 at 10:31:27AM -0800, Linus Torvalds wrote: > > > On Thu, 18 Nov 2004, Miklos Szeredi wrote: > > > > Well, killing the fuse process _will_ make the system come back to > > life, since then all the dirty pages belonging to the filesystem will > > be discarded. > > They will? Why? They're still mapped into other processes, still dirty. > How do they go away? If the filesystem a dirty page is mapped against ceases to exist, wouldn't it make sense to destroy the page? All such user processes can receive SIGBUS and crash. This is sort of a general problem with a filesystem on a "removable" device like a USB stick, and it seems the only sane solution is to blow all the mappings against that filesystem away. Of course, it sucks since the final result will be a crash, but mmap() isn't a reliable interface for accessing media that might go away... So, a reasonable solution would be to detect when a user fs process dies, and initiate a forced unmount procedure where you walk all the pages mapped against that filesystem and blow them away. Similarly for a case like pulling a USB reader out while it's being written to (you could nag the user to reinsert, but that might be impossible). This doesn't solve the deadlock as such except as a sort of panic-recovery hack, but it seems sensible in general. -J