mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Phil Howard <phil-linux-kernel@ipal.net>
To: linux-kernel@vger.kernel.org
Subject: Re: Disk hardware caching, performance, and journalling
Date: Sat, 24 Nov 2001 15:57:39 -0600	[thread overview]
Message-ID: <20011124155739.A4372@vega.ipal.net> (raw)
In-Reply-To: <3BFFE8A2.1010708@rueb.com> <3BFFF021.D963B467@zip.com.au>
In-Reply-To: <3BFFF021.D963B467@zip.com.au>

On Sat, Nov 24, 2001 at 11:08:17AM -0800, Andrew Morton wrote:

| With writebehind the disk can write that entire track in pretty
| much a single spin.  But if we're waiting on the result of each
| request we'll lose revolutions.  In synchronous mode it's going
| to take three or four spins to write a track.
|  
| > So what are the implications here for journalling?  Do I have to turn
| > off caching and suffer a huge performance hit?
| 
| In theory, yes.  In my opinion, no.  For ext3, at least.  Caching
| isn't bad per-se.  It's reordering which can break the journalling
| constraints.  But given that the journal is, we hope, a strictly
| ascending and (we really hope) contiguous chunk of blocks, it's
| quite unlikely that the disk will decide to write them in an
| unexpected order.  This is especially true if the journal was
| created when the disk was relatively unfragmented.
| 
| And if the disk _does_ write them in the wrong order, it has
| to be specifically the journal commit block which was written
| prior to some data blocks.  And you need to lose power (not
| just crash) prior to the data blocks hitting disk.  It's a
| very small time window containing an improbable occurrence.
| 
| Now that's all just vigorous handwaving, and may be wrong,
| and yes, we really need a way of propagating barriers down
| to the request queue.  But I've not seen a whisker of a report
| which indicates that write reordering has caused on-recovery
| corruption.

What if (and maybe it is so, or maybe not) the write cache does
write-back (or write-behind) zones per track?  That is, when it
gets a write request either when the cache is not dirty, or is
in the same _physical_ track that everything that is in there
dirty goes into, it gets queued.  Then when some time passes,
or a request goes to a new track, it will write that track now
and move on.  IWSTM this gives you the advantage of "one spin"
writes for sequential data, and still keeps the order right for
journaled data.  Could they be doing this?

-- 
-----------------------------------------------------------------
| Phil Howard - KA9WGN |   Dallas   | http://linuxhomepage.com/ |
| phil-nospam@ipal.net | Texas, USA | http://phil.ipal.org/     |
-----------------------------------------------------------------

  parent reply	other threads:[~2001-11-24 21:58 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-11-24 18:36 Steve Bergman
2001-11-24 19:08 ` Andrew Morton
2001-11-24 19:39   ` Florian Weimer
2001-11-24 21:57   ` Phil Howard [this message]
2001-11-25  9:22   ` Chris Wedgwood
2001-11-24 19:39 ` Mark Hahn
2001-11-25  9:23   ` Chris Wedgwood
2001-11-25 21:45     ` Kevin P. Fleming
2001-11-25 22:11       ` Chris Wedgwood
2001-11-25 22:29         ` Mark Hahn
2001-11-26  1:10       ` Bernd Eckenfels
2001-11-25  9:19 ` Chris Wedgwood

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=20011124155739.A4372@vega.ipal.net \
    --to=phil-linux-kernel@ipal.net \
    --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

all inboxes | Powered by JetHome®