[ Saturday, September 18, 1999 ] Ingo Molnar wrote:
> James, are you patching against the latest RAID source? 2.3.18 has a
> painfully outdated RAID driver. (i'm working on porting the newest stuff
> to 2.3 right now)
I guess so... I needed 2.3.1[78] for a third-party binary-only module,
but couldn't find any 2.3-based in the raid0145 patches... great to
hear you're working on the port... WRT feature freeze, does this mean
2.4 will still have broken raid?
Are duplicate ctl_table/ctl_table_header's between md.c and raid1.c
acceptable? I don't see any simple method available to cleanly pass
the pointer to the static int over to raid1.c, although I'd certainly
rather do something like:
--- linux-2.2.11_orig/drivers/block/md.c Sat Sep 18 13:02:08 1999
+++ linux-2.2.11/drivers/block/md.c Sat Sep 18 13:01:02 1999
@@ -89,12 +89,15 @@
*/
static int sysctl_speed_limit = 100;
+static int sysctl_raid1_balance = 128;
static struct ctl_table_header *md_table_header;
static ctl_table md_table[] = {
{DEV_MD_SPEED_LIMIT, "speed-limit",
&sysctl_speed_limit, sizeof(int), 0644, NULL, &proc_dointvec},
+ {DEV_MD_RAID1_BALANCE, "raid1-balance",
+ &sysctl_raid1_balance, sizeof(int), 0644, NULL, &proc_dointvec},
{0}
};
In raid1_make_request, though,
if (conf->sect_count >= mirror->sect_limit)
switch_disks = 1;
It seems like in the bonnie case of 8KB blocks, with a sect_limit of
64KB, we end up switching after 7 requests to the drive, as the 8th
request would end up with sect_count == sect_limit (since sect_count
is updated before the test), so replacing with > should help implement
intended functionality, I would imagine. As it stands, I don't see
how you could ever get 128 sectors from the same drive, barring drive
failure of the mirror :)
On a philosophical level, it looks like the hard-coded 128 was never meant
to stay permanent, since each raid gets its own sect_limit... so perhaps
you'd rather see /proc/dev/md/md?/{speed-limit,raid1-balance,*} instead?
While balancing should be adjustable as different raid's may have
different optimal points, I think even speed-limit could go down a
level, as someone may wish an otherwise-idle root-raid to resync at a
minimum of 2 MB/sec (fearing exposure before the resync is finished),
while with 2 raid5's (one in degraded mode) on the same raid controller,
they might want the degraded raid5 to resync at a much lower priority,
to help minimize effect on the more performance-critical non-degraded
raid5 *shrug*
Sure, this is a contrived situation, but as raid splits into the 2 realms
of high-redundancy, good-performance, rarely-hit (raid1, esp. root)
and good-redundancy, high-performance, pegged-all-the-time (large data
raid{5,10,50}), it looks like global variables for all raids may fade in
usefulness. Of course, your structure already in place seems to reflect
that realization, so perhaps its just a matter of lower priority while
other critical aspects (getting into 2.4 :) are taken care of.
> > simple, just pulling back in the code from 2.2.11-ac3. I'm hoping that
> > the sysctl getting ripped out was more for acceptance, since speed-limit
> > I still think was a good idea, even as a maximum, as it helped make the
> > array more usable...
>
> sure, and it's present and used in the latest RAID driver ...
Great... good to hear :) Just wish I hadn't assumed that no raid patch
for 2.3.x in daemons/raid/alpha/ meant that it had already been accepted
into 2.3 :)
> maybe the fact that you are using the old driver explains why you see bad
> RAID1 performance? What performance do you see with the newest RAID driver
> on 2.2.12?
I'm actually not doing raid1 at the moment... this was simply in response
to the poor raid1 performance thread, as I plan to be doing raid1 (across
two adaptec 7895's) in a few weeks, and could see the adjustable balancing
helping me out.
James
--
Miscellaneous Engineer --- IBM Netfinity Performance Development
