From: Chris Mason <clm@fb.com>
To: "dsterba@suse.cz" <dsterba@suse.cz>
Cc: "wangsl.fnst@cn.fujitsu.com" <wangsl.fnst@cn.fujitsu.com>,
"linux-btrfs@vger.kernel.org" <linux-btrfs@vger.kernel.org>,
CML <CML@fb.com>,
"sbehrens@giantdisaster.de" <sbehrens@giantdisaster.de>
Subject: Re: [PATCH] Btrfs: only fua the first superblock when writting supers
Date: Fri, 3 Jan 2014 17:30:05 +0000 [thread overview]
Message-ID: <1388770244.29987.0.camel@ret.masoncoding.com> (raw)
In-Reply-To: <20140103170350.GP6498@twin.jikos.cz>
On Fri, 2014-01-03 at 18:03 +0100, David Sterba wrote:
> On Fri, Jan 03, 2014 at 06:22:57PM +0800, Wang Shilong wrote:
> > We only intent to fua the first superblock in every device from
> > comments, fix it.
>
> Good catch, this could gain some speedup when there are up to 2 less
> flushes.
>
> There's one thing that's a different from currnet behaviour:
> Without this patch, all the superblocks are written with FUA, now only
> the first one, so my question is what if the first fails and the others
> succeed but do not get flushed immediatelly?
>
> This is more of a theoretical scenario, and if the 1st superblock write
> fails more serious problems can be expected. But let's say the write
> error of 1st is transient, do you or others think that it's reasonable
> to try to write all the remainig sb's with FUA?
Not a bad idea, if we get a failure on the first SB, fua the others? I
think it does make sense to do the others non-fua, just because they
only get used in emergencies anyway.
-chris
prev parent reply other threads:[~2014-01-03 17:30 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-03 10:22 [PATCH] Btrfs: only fua the first superblock when writting supers Wang Shilong
2014-01-03 17:03 ` David Sterba
2014-01-03 17:30 ` Chris Mason [this message]
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=1388770244.29987.0.camel@ret.masoncoding.com \
--to=clm@fb.com \
--cc=CML@fb.com \
--cc=dsterba@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
--cc=sbehrens@giantdisaster.de \
--cc=wangsl.fnst@cn.fujitsu.com \
/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.