public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Ookhoi <ookhoi@dds.nl>
To: Linas Vepstas <linas@backlot.linas.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: fsck, raid reconstruction & bad bad 2.4.3
Date: Tue, 17 Apr 2001 13:53:38 +0200	[thread overview]
Message-ID: <20010417135338.E1546@humilis> (raw)
In-Reply-To: <20010415181825.40FBB1BA03@backlot.linas.org>
In-Reply-To: <20010415181825.40FBB1BA03@backlot.linas.org>; from linas@backlot.linas.org on Sun, Apr 15, 2001 at 01:18:25PM -0500

Hi Linas Vepstas,

(nice name ;-)

> First problem:  In kernel-2.4.2 and earlier, if the machine is not cleanly
> shut down, then upon reboot, RAID reconstruction is automatically started.
> (For RAID-1, this more-or-less ammounts to copying the entire contents
> of one disk partition on one disk to another).   The reconstruction
> code seems to be clever: it will try to use the full bandwidth when
> the system is idle, and it will throttle back when busy.  It will
> only throttle back so far: it tries to maintain at least a minimum amount
> of work going, in order to gaurentee forward progress even on a busy system.
> 
> The problem:  this dramatically slows fsck after an unclean shut-down.
> You can hear the drives machine-gunning.  I haven't stop-watch timed it,
> but its on the order of 5x slower to fsck a raid partition when there's
> reconstruction going on, then when the raid thinks its clean.  This
> makes unclean reboots quite painful.
> 
> (There is no config file to disable/alter this .. no work-around that I
> know of ..)

One possible 'work-around' is to use a journaling filesystem (like
reiserfs) which eliminates the fsck after a unclean shutdown. It's very
nice to have a crashed system back online fast. The raid sync makes the
system a bit slow, but as you said, it syncs at full speed when idle,
and is nice when less idle. :-)

	Ookhoi

  parent reply	other threads:[~2001-04-17 11:54 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-04-15 18:18 fsck, raid reconstruction & bad bad 2.4.3 Linas Vepstas
     [not found] ` <9bcoph$1vj$1@ns1.clouddancer.com>
2001-04-15 19:59   ` Colonel
2001-04-16  1:14     ` Bernd Eckenfels
2001-04-16  2:23       ` Jesse Pollard
2001-04-16  2:38         ` Jonathan Lundell
2001-04-16  2:51           ` Jesse Pollard
2001-04-16 19:06             ` Jakob Østergaard
2001-04-16  4:03         ` Bernd Eckenfels
2001-04-16 14:16 ` fsck, raid reconstruction & bad bad 2.4.3 + some numbers Francois Romieu
2001-04-17 11:53 ` Ookhoi [this message]
     [not found] <p05100b09b7000a8c3bc9@207.213.214.34>
2001-04-16  4:05 ` fsck, raid reconstruction & bad bad 2.4.3 Bernd Eckenfels

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=20010417135338.E1546@humilis \
    --to=ookhoi@dds.nl \
    --cc=linas@backlot.linas.org \
    --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