mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Nathan Scott <nathans@sgi.com>
To: Martin MOKREJ? <mmokrejs@ribosome.natur.cuni.cz>
Cc: linux-xfs@oss.sgi.com, linux-kernel@vger.kernel.org
Subject: Re: Filesystem performance on 2.4.28-pre3 on hardware RAID5.
Date: Wed, 3 Nov 2004 11:17:26 +1100	[thread overview]
Message-ID: <20041103111726.B5524750@wobbly.melbourne.sgi.com> (raw)
In-Reply-To: <41878432.5060904@ribosome.natur.cuni.cz>; from mmokrejs@ribosome.natur.cuni.cz on Tue, Nov 02, 2004 at 01:57:22PM +0100

On Tue, Nov 02, 2004 at 01:57:22PM +0100, Martin MOKREJ? wrote:
> I retested with blocksize 1024, instead of 512 (default) which causes problems:

4K is the default blocksize, not 1024 or 512 bytes.  From going
through all your notes, the default mkfs parameters are working
fine, and changing to a 512 byte blocksize (-blog=9 / -bsize=512)
is where the VM starts to see problems.

I don't have a device the size of yours handy on my test box, nor
do I have as much memory as you -- but I ran similar bonnie++
commands with -bsize=512 filesystems on a machine with very little
memory, and a filesystem and file size exponentially larger than
available memory, and it ran to completion without problems.
I did see vastly more buffer_heads being created than with the
default mkfs parameters (as we'd expect with that blocksize) but
it didn't cause me any VM problems.

> How can I free the buffer_head without rebooting? I'm trying to help myself with

AFAICT, there is no way to do this without a reboot.  They are
meant to be reclaimed (and were reclaimed on my test box) as
needed, but they don't seem to be for you.

This looks alot like a VM balancing sort of problem to me (that
6G of memory you have is a bit unusual - probably not a widely
tested configuration on i386... maybe try booting with mem=1G
and see if that changes anything?), so far it doesn't seem like
XFS is at fault here at least.

cheers.

-- 
Nathan

  parent reply	other threads:[~2004-11-03  0:18 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-29 11:10 mmokrejs
2004-10-31 23:24 ` Nathan Scott
     [not found]   ` <418574FB.2020907@ribosome.natur.cuni.cz>
     [not found]     ` <20041031223214.GB690@frodo>
     [not found]       ` <41878432.5060904@ribosome.natur.cuni.cz>
2004-11-03  0:17         ` Nathan Scott [this message]
  -- strict thread matches above, loose matches on Subject: below --
2004-10-28 22:43 Martin MOKREJŠ
2004-10-29  7:31 ` Nathan Scott

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=20041103111726.B5524750@wobbly.melbourne.sgi.com \
    --to=nathans@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xfs@oss.sgi.com \
    --cc=mmokrejs@ribosome.natur.cuni.cz \
    /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®