From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ric Wheeler Subject: Re: topics for the file system mini-summit Date: Sat, 03 Jun 2006 11:07:13 -0400 Message-ID: <4481A5A1.204@emc.com> References: <44762552.8000906@emc.com> <20060601021908.GL10420@goober> <44819398.4030603@emc.com> <44819909.5020801@linux.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Valerie Henson , linux-fsdevel@vger.kernel.org, trond.myklebust@fys.uio.no Return-path: Received: from mexforward.lss.emc.com ([128.222.32.20]:19410 "EHLO mexforward.lss.emc.com") by vger.kernel.org with ESMTP id S1750945AbWFCPQP (ORCPT ); Sat, 3 Jun 2006 11:16:15 -0400 To: Arjan van de Ven In-Reply-To: <44819909.5020801@linux.intel.com> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Arjan van de Ven wrote: > Ric Wheeler wrote: > >>> >> Any thoughts about what the right semantics are for properly doing a >> forced unmount and how whether it is doable near term (as opposed to >> the more strategic/long term issues laid out in this thread) ? > > > I would like to ask you take one step back; in the past when I have seen > people want "forced unmount" they wanted instead somethings else that > they > thought (at that point incorrectly) forced unmount would solve. > > there's a few things an unmount does > 1) detach from the namespace (tree) > 2) shut down the filesystem to > 2a) allow someone else to mount/fsck/etc it > 2b) finish stuff up and put it in a known state (clean) > 3) shut down IO to a fs for another node to take over > (which is what the "incorrectly" is about technically) > > We have 20-30 100GB file systems on a single box (to avoid the long fsck time). When you hit an issue with one file system, say a panic, or a set of file systems (dead drive) that might take out 5 file systems, we want to be able to keep the box up since it is still serving up something like 2.5TB of storage to the user ;-) So what I want is all of the following: (1) do your 2a - be able to fsck and repair corruptions and then hopefully remount that file system without a reboot of the box. (2) leave all other file systems (including those of the same type) running without error (good fault isolation). (3) I don't want to try and clean up that file system state - error out any existing IO's, perfectly fine to have processes using get blown away. In effect, treat it (from the file system point of view) just like you would a power outage & reboot. You should replay the journal & recover only after you get the disk back. (4) make sure that a hung disk or panic'ed file system does not prevent an intentional reboot. In a conversation about this with Trond, I think that he has some other specific motivations from an NFS point of view as well. ric ric