All of lore.kernel.org
 help / color / mirror / Atom feed
From: Philip Molter <philip@corp.texas.net>
To: Mike Hardy <mhardy@h3c.com>
Cc: linux-raid@vger.kernel.org
Subject: Re: Software RAID & Filesystem Cache
Date: Thu, 05 Aug 2004 12:34:00 -0500	[thread overview]
Message-ID: <41126F88.7040006@corp.texas.net> (raw)
In-Reply-To: <411268C7.9070804@h3c.com>

Mike Hardy wrote:

> 
> I was just researching a similar problem. I turned up a few things that 
> pointed at the filesystem readahead values/strategies, apparently those 
> things changed quite a bit between 2.4 and 2.6. You might try twiddling 
> those knobs, and you can find some linux-kernel threads where various 
> values were tested
> 
> Also, for my specific case, I found that the default I/O scheduler in 
> Fedora Core 2, the "Complete Fair Queueing" scheduler ('cfq') wasn't as 
> good as the 'deadline' scheduler, and neither was good as the 
> 'anticipatory' scheduler. So now I boot with the kernel command line 
> parameter 'scheduler=as' and things are faster. That's extremely 
> workload specific though - so you might run your own scheduler derby and 
> see what works.
> 
> The readahead is the first place I'd look though. All in all, it appears 
> that 2.6 kernels need a great deal more I/O tuning before they can be 
> put in production. While I like the flexibility that's available, the 
> default settings seem to be a major negative change from 2.4. This sort 
> of thing is just now being quantified and hopefully it gets sorted out 
> in the next couple of releases

Hi Mike,

Thanks for the response.  I run the system under the anticipatory 
scheduler, too, but I tried all of this under the default, deadline and 
as schedulers with no difference between the two.

My first suspicion was readahead as well, but I couldn't find any of the 
sysctl options to control readahead in the kernel (as there were under 
2.4).  I did mess around with readahead directly on the drives, but as 
expected, that had no effect.  I tried other reading options, but none 
seemed to have any effect.  The RAID seemed very insistent on reading 
all of that data.

I was flummoxed.

Philip

  parent reply	other threads:[~2004-08-05 17:34 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-05 16:31 Software RAID & Filesystem Cache Philip Molter
     [not found] ` <411268C7.9070804@h3c.com>
2004-08-05 17:34   ` Philip Molter [this message]
  -- strict thread matches above, loose matches on Subject: below --
2004-08-05 17:49 Mike Hardy
2004-08-05 18:54 ` Philip Molter
2004-08-07 14:04 ` Philip Molter

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=41126F88.7040006@corp.texas.net \
    --to=philip@corp.texas.net \
    --cc=linux-raid@vger.kernel.org \
    --cc=mhardy@h3c.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.