From: Fernando Serboncini <fserb@campogeral.com.br>
To: linux-raid@vger.kernel.org
Subject: RAID5 resync blocking on 2.6.0-test11
Date: Thu, 11 Dec 2003 22:25:57 -0200 [thread overview]
Message-ID: <3FD90B15.8050905@campogeral.com.br> (raw)
Hi, I sent this e-mail to the LKML yesterday, that's when I found the
linux-raid list. ;)
So hi, LinuxRaid
I've just installed a software-RAID 5 on my Alpha (miata) Workstation
500au with Kernel 2.6.0-test11. The RAID is made of 4 Western Digital
250Gb HDs on a promise-ata-133tx2.
The initial raidstart and mke2fs worked fine. After the initial sync, a
clean boot and a new raidstart, the /proc/mdstat reported that the drive
was at "resync" (/var/log/messages says that "raid array is not clean").
The problem is, the resync was blocking the /dev/md0. So, when I did a
'mount /dev/md0', it blocked until the resync was done (and it was a
looong time for a nearly 1TB RAID).
Looking through driver/md code I've realized that md_do_sync() was the
real devil. After a few diffs with 2.4.23 code I've realized that at the
speed limiter part of the function, the old "current->nice = " lines
were deleted.
After a few more search (and looking through LXR) at
/fs/jffs2/background.c and /net/bluetooth/bnep/core.c I've realized that
some people have changed "current->nice =" statements to
"set_user_nice(current,...)" ones.
Done that. The RAID worked just fine (still resyncing at boot, not fully
tested yet) but don't block mounts anymore (btw, mount returns a lot
faster than with 2.4.23).
Since I'm no kernel (nor RAID) expert (first post here, btw), just
wandering if I did something really stupid or not.
Also, is this an Alpha-only issue? Or a 2.6.0 issue?
Anyway, here follows the patch for what I've done.
thanks for the attention.
Fernando Serboncini
--- linux-2.6.0-test11/drivers/md/md.c 2003-11-26 18:43:29.000000000 -0200
+++ linux/drivers/md/md.c 2003-12-10 23:29:33.000000000 -0200
@@ -3290,6 +3290,8 @@
currspeed =
(j-mddev->resync_mark_cnt)/2/((jiffies-mddev->resync_mark)/HZ +1) +1;
if (currspeed > sysctl_speed_limit_min) {
+ set_user_nice(current,19);
+
if ((currspeed > sysctl_speed_limit_max) ||
!is_mddev_idle(mddev)) {
current->state = TASK_INTERRUPTIBLE;
@@ -3297,6 +3299,8 @@
goto repeat;
}
}
+ else
+ set_user_nice(current,-20);
}
printk(KERN_INFO "md: md%d: sync done.\n",mdidx(mddev));
/*
next reply other threads:[~2003-12-12 0:25 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-12-12 0:25 Fernando Serboncini [this message]
2003-12-16 20:20 ` RAID5 resync blocking on 2.6.0-test11 Fernando Serboncini
2004-03-16 23:23 ` Neil Brown
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=3FD90B15.8050905@campogeral.com.br \
--to=fserb@campogeral.com.br \
--cc=linux-raid@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;
as well as URLs for NNTP newsgroup(s).