linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] Btrfs: only fua the first superblock when writting supers
@ 2014-01-03 10:22 Wang Shilong
  2014-01-03 17:03 ` David Sterba
  0 siblings, 1 reply; 3+ messages in thread
From: Wang Shilong @ 2014-01-03 10:22 UTC (permalink / raw)
  To: linux-btrfs

We only intent to fua the first superblock in every device from
comments, fix it.

Signed-off-by: Wang Shilong <wangsl.fnst@cn.fujitsu.com>
---
 fs/btrfs/disk-io.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 9417b73..b016657 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -3142,7 +3142,10 @@ static int write_dev_supers(struct btrfs_device *device,
 		 * we fua the first super.  The others we allow
 		 * to go down lazy.
 		 */
-		ret = btrfsic_submit_bh(WRITE_FUA, bh);
+		if (i == 0)
+			ret = btrfsic_submit_bh(WRITE_FUA, bh);
+		else
+			ret = btrfsic_submit_bh(WRITE_SYNC, bh);
 		if (ret)
 			errors++;
 	}
-- 
1.8.3.1


^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH] Btrfs: only fua the first superblock when writting supers
  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
  0 siblings, 1 reply; 3+ messages in thread
From: David Sterba @ 2014-01-03 17:03 UTC (permalink / raw)
  To: Wang Shilong; +Cc: linux-btrfs, cml, sbehrens

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?


david

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] Btrfs: only fua the first superblock when writting supers
  2014-01-03 17:03 ` David Sterba
@ 2014-01-03 17:30   ` Chris Mason
  0 siblings, 0 replies; 3+ messages in thread
From: Chris Mason @ 2014-01-03 17:30 UTC (permalink / raw)
  To: dsterba@suse.cz
  Cc: wangsl.fnst@cn.fujitsu.com, linux-btrfs@vger.kernel.org, CML,
	sbehrens@giantdisaster.de

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


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2014-01-03 17:30 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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 is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).