From: Liu Bo <liub.liubo@gmail.com>
To: Jan Schmidt <list.btrfs@jan-o-sch.net>
Cc: Arne Jansen <sensille@gmx.net>,
linux-btrfs <linux-btrfs@vger.kernel.org>,
"Behrens, Stefan" <sbehrens@strato-rz.de>
Subject: Re: [PATCH v2] Btrfs: remove superblock writing after fatal error
Date: Fri, 03 Aug 2012 11:20:15 +0800 [thread overview]
Message-ID: <501B436F.1040105@gmail.com> (raw)
In-Reply-To: <501A8E7A.6070601@jan-o-sch.net>
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
>
next prev parent reply other threads:[~2012-08-03 3:20 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-01 11:45 [PATCH v2] Btrfs: remove superblock writing after fatal error Stefan Behrens
2012-08-01 12:02 ` Liu Bo
2012-08-01 13:07 ` Jan Schmidt
2012-08-01 13:31 ` Liu Bo
2012-08-01 13:56 ` Arne Jansen
2012-08-01 14:31 ` Stefan Behrens
2012-08-02 10:30 ` Stefan Behrens
2012-08-02 10:36 ` Liu Bo
2012-08-02 11:18 ` Arne Jansen
2012-08-02 11:34 ` Liu Bo
2012-08-02 11:40 ` Arne Jansen
2012-08-02 11:57 ` Liu Bo
2012-08-02 13:46 ` Arne Jansen
2012-08-02 13:57 ` David Sterba
2012-08-02 14:01 ` Arne Jansen
2012-08-02 14:28 ` Jan Schmidt
2012-08-03 3:20 ` Liu Bo [this message]
2012-08-03 4:59 ` Jan Schmidt
2012-08-02 15:06 ` cwillu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=501B436F.1040105@gmail.com \
--to=liub.liubo@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=list.btrfs@jan-o-sch.net \
--cc=sbehrens@strato-rz.de \
--cc=sensille@gmx.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.