linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Chris Mason <mason@suse.com>
To: Hans Reiser <reiser@namesys.com>
Cc: linux-fsdevel@vger.kernel.org, akpm@osdl.org,
	reiserfs-dev@namesys.com,
	Martin Steigerwald <Martin@lichtvoll.de>
Subject: Re: [PATCH 0/2] enable write barriers by default
Date: Sat, 5 Aug 2006 08:45:19 -0400	[thread overview]
Message-ID: <20060805124519.GH1048@watt.suse.com> (raw)
In-Reply-To: <44D412FB.8080902@namesys.com>

On Fri, Aug 04, 2006 at 09:39:39PM -0600, Hans Reiser wrote:
>
> Please explain when cache flushes occur now.

Without them enabled? Never.  With them enabled on every commit and/or
fsync.

> For every fsync on a drive
> that does not support write barriers?  Which drives support it?

Most IDE and SATA drives.

> 
> Did this only get enabled now because it is only now that someone from
> the press is paying attention to it?

No, it has been enabled by default in the SUSE kernels for a long time
(two enterprise releases now sles9 and sles10).  I wanted to bring the
discussion about it into mainline.

> 
> This is the price we paid for losing Andre, yes?

This is the price we pay for drives turning writeback cache on by
default.  It happens for performance, because without tagging write
though caches give horrible write speeds.  It is slower than not doing
IO (writeback cache) but faster than turning writeback caches off.

Exact benchmarks vary by drive, but it is never slower than
write-through caching, and almost always faster.

-chris


      reply	other threads:[~2006-08-05 12:45 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-08-04 13:51 [PATCH 0/2] enable write barriers by default Chris Mason
2006-08-04 13:53 ` [PATCH 1/2] Make reiserfs default to barrier=flush Chris Mason
2006-08-04 13:55 ` [PATCH 2/2] make ext3 mount default to barrier=1 Chris Mason
2006-08-05  3:39 ` [PATCH 0/2] enable write barriers by default Hans Reiser
2006-08-05 12:45   ` 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=20060805124519.GH1048@watt.suse.com \
    --to=mason@suse.com \
    --cc=Martin@lichtvoll.de \
    --cc=akpm@osdl.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=reiser@namesys.com \
    --cc=reiserfs-dev@namesys.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 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).