public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Dieter Stüken" <stueken@conterra.de>
To: linux-kernel@vger.kernel.org
Cc: Helge Hafting <helge.hafting@aitel.hist.no>, hzhong@gmail.com
Subject: Re: ext3 metadata performace
Date: Fri, 12 May 2006 12:11:38 +0200	[thread overview]
Message-ID: <44645F5A.7000209@conterra.de> (raw)
In-Reply-To: <44642CBD.4000305@aitel.hist.no>

Helge Hafting wrote:
> Dieter Stüken wrote:
>> Would it be make sense for ext3, to disable synchronous writes even
>> for metadata (similar to the "data=writeback" option)?
> 
> Turning off synchronous writes like this won't work!
> The battery-backed cache can help you in that you can consider
> data "written" once it is transferred to that cache.  Metadata must still
> go synchronously into the cache though, or you get a broken fs
> if ever your machine crash in the middle of a transaction. (Leaving
> an update halfway in that battery cache, and halfway in main memory.
> Then main memory dies from the power cut / reboot.)
> 
> The caching controller should report back to the linux device driver
> that "data is committed" as soon as it hits the cache - no need to
> wait for it to actually hit the platters.  This can help performance with
> bursty writes tremendously - but it won't help you with long-lasting writes
> as you will then be limited by platter speed as soon as the battery cache
> is completely full.

The battery buffered cache is about 100Mb compared to 8k or 16k of the
disk buffer cache itself. So it won't become full that fast...

I just tested the same with my other controller (a 3ware 9550SX) which
has an option to configure explicitly if a write is acknowledged as
soon as the data is saved to the (buffered) memory or if it will delay
the acknowledge until data got written to disk. So this is similar to
enabling/disabling the disk cache on a plain disk. I did not found a
way to configure this on my older 3ware 9500S controller, even if it
has a battery backup, too (will ask 3ware about this).

Hua Zhong wrote:
>> If you mean the disk cache is reliable with the battery, then it 
 >> should be done by the block layer that a write barrier doesn't
>> translate into a SYNC (or whatever it is called). Instead, data is 
 >> considered synced to disk as soon as it hits the cache.
>> 
>> It's really nothing to do with EXT3. It's doing the right thing.

I read something about "write barriers", but I don't know if these are
already used by my current 2.6.15 (I may try to use the actual kernel
tomorrow). Is there a difference between a SATA disk and a SCSI disk?
(which is emulated by my 3Ware controllers).

Dieter.

  reply	other threads:[~2006-05-12 10:11 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-11 14:11 ext3 metadata performace Dieter Stüken
2006-05-11 15:43 ` Avi Kivity
2006-05-11 18:46   ` Miquel van Smoorenburg
2006-05-12  0:36 ` Hua Zhong
2006-05-12  6:35 ` Helge Hafting
2006-05-12 10:11   ` Dieter Stüken [this message]
     [not found] <6bkbC-4V9-27@gated-at.bofh.it>
2006-05-12  0:12 ` Robert Hancock

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=44645F5A.7000209@conterra.de \
    --to=stueken@conterra.de \
    --cc=helge.hafting@aitel.hist.no \
    --cc=hzhong@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    /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