From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arjan van de Ven Subject: Re: topics for the file system mini-summit Date: Sat, 03 Jun 2006 16:13:29 +0200 Message-ID: <44819909.5020801@linux.intel.com> References: <44762552.8000906@emc.com> <20060601021908.GL10420@goober> <44819398.4030603@emc.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 Return-path: Received: from fmr18.intel.com ([134.134.136.17]:27851 "EHLO orsfmr003.jf.intel.com") by vger.kernel.org with ESMTP id S1751658AbWFCONr (ORCPT ); Sat, 3 Jun 2006 10:13:47 -0400 To: Ric Wheeler In-Reply-To: <44819398.4030603@emc.com> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org 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)