From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-f174.google.com ([209.85.214.174]:56987 "EHLO mail-ob0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751265Ab2HCDUU (ORCPT ); Thu, 2 Aug 2012 23:20:20 -0400 Received: by obbuo13 with SMTP id uo13so417433obb.19 for ; Thu, 02 Aug 2012 20:20:20 -0700 (PDT) Message-ID: <501B436F.1040105@gmail.com> Date: Fri, 03 Aug 2012 11:20:15 +0800 From: Liu Bo MIME-Version: 1.0 To: Jan Schmidt CC: Arne Jansen , linux-btrfs , "Behrens, Stefan" Subject: Re: [PATCH v2] Btrfs: remove superblock writing after fatal error References: <1343821552-28726-1-git-send-email-sbehrens@giantdisaster.de> <50191AD3.9080401@gmail.com> <50192A11.3060109@jan-o-sch.net> <50192FCE.30006@gmail.com> <50193DDA.20504@giantdisaster.de> <501A56E3.3080401@giantdisaster.de> <501A583D.8030600@gmail.com> <501A61ED.3000908@gmx.net> <501A65B9.5060004@gmail.com> <501A6731.4000405@gmx.net> <501A6B0D.6050303@gmail.com> <501A84CA.10604@gmx.net> <501A8E7A.6070601@jan-o-sch.net> In-Reply-To: <501A8E7A.6070601@jan-o-sch.net> Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-btrfs-owner@vger.kernel.org List-ID: On 08/02/2012 10:28 PM, Jan Schmidt wrote: > On Thu, August 02, 2012 at 15:46 (+0200), Arne Jansen wrote: >> On 02.08.2012 13:57, Liu Bo wrote: >>> Anyway, for now, our error flag has only been stored in memory, so what >>> about just keep it until we find a graceful way? >> >> Yeah, we need this patch to restore consistency. We can define a fixed >> area on disk (e.g. behind the superblock) where we can write the flag >> to without risking the superblock. > > At least we all agree that we need this patch, fine. > > We don't yet agree that we need a place to store a "please consider fsck" flag. > Can I please get one concrete example in which situation we > > a) do detect the user should really do a file system check AND > b) do not abort the transaction to clean the mess up? > > (An example on how we could fail transaction cleanup is also accepted). > Unfortunately I don't have such an example either. Since we always get COW on metadata, I believe that it's ok to just roll back on failure. > If such a situation doesn't exist, there's no need for this flag. The fact that > ext has such a flag doesn't convince me, probably because I know nothing about > ext. I can imagine that they can detect file system errors without the ability > to return to a potentially older consistent state. > This error flag is also used to indicate filesystem's error state for transaction cleanup, so keeping it in memory is reasonable. thanks, liubo > Thanks, > -Jan >