From: linas@backlot.linas.org (Linas Vepstas)
To: jakob@ostenfeld.dk, linux-kernel@vger.kernel.org, miku@iki.fi,
neilb@cse.unsw.edu.au
Subject: fsck, raid reconstruction & bad bad 2.4.3
Date: Sun, 15 Apr 2001 13:18:25 -0500 (CDT) [thread overview]
Message-ID: <20010415181825.40FBB1BA03@backlot.linas.org> (raw)
Hi,
I want to report a trio of raid-related problems. The third one is
very serious, and effectively prevents 2.4.3 from being usable (by me).
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 ..)
--------
The second problem: oparallelizing fsck doesn't realize that different
/dev/md raid volumes are on the same physical disks, and thus tries
to parallelize .... again slowing things down. There is a work-around,
modify /etc/fstab to set the rder of fsck's. However, I doubt the HOWTO
really gets into this .... it would be nice to get fsck to 'do the
right thing'.
----------
Third problem:
I just tried boot 2.4.3 today. (after an unclean shutdown) fsck runs
at a crawl on my RAID-1 volume. It would take all day (!! literally)
to fsck. The disk-drive activity light flashes about once a second,
maybe once every two seconds. (with a corresponding click from the
drive).
On 2.4.2 kernels, the disk activity light is constantly on... and the
fsck proceeds apace.
Whatever it is that changed in 2.4.3, it makes unclean reboots
impossible ...
--linas
next reply other threads:[~2001-04-15 18:19 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <9bcoph$1vj$1@ns1.clouddancer.com>
2001-04-15 18:18 ` Linas Vepstas [this message]
2001-04-15 19:59 ` Colonel
2001-04-16 1:14 ` Bernd Eckenfels
2001-04-16 2:23 ` Jesse Pollard
2001-04-16 4:03 ` Bernd Eckenfels
2001-04-16 2:38 ` Jonathan Lundell
2001-04-16 2:51 ` Jesse Pollard
2001-04-16 19:06 ` Jakob Østergaard
2001-04-16 14:16 ` fsck, raid reconstruction & bad bad 2.4.3 + some numbers Francois Romieu
2001-04-17 11:53 ` fsck, raid reconstruction & bad bad 2.4.3 Ookhoi
[not found] <p05100b09b7000a8c3bc9@207.213.214.34>
2001-04-16 4:05 ` 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=20010415181825.40FBB1BA03@backlot.linas.org \
--to=linas@backlot.linas.org \
--cc=jakob@ostenfeld.dk \
--cc=linux-kernel@vger.kernel.org \
--cc=miku@iki.fi \
--cc=neilb@cse.unsw.edu.au \
/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®