This message sort of came out of the blue to the linux-raid mailing list -
it sounds like something that has been a discussion on the linux-kernel
list, but someone decided it was time to cross-post to the linux-raid list.
Unfortunately, the context was lost completely.
I have been the victim of the VM stuff for several kernels now - completely
bringing several machines to their knees. My solution, thus far, has been to
upgrade to 2.2.18-pre15 (seems to be the most stable), I have been sucessful
in installing the 2.2.17-RAID patches to continue the software RAID setups
that I have.
I am wondering if this message, and the patch included in it, indicates that
the VM problem is related to software RAID? If so, does this patch fix it?
If this patch fixes it, is there any chance it will be tested? It is nice to
get patches that fix things, but only ones that work. I dont see the point
putting time into finding the problem, developing a patch, and then
distributing the patch but not testing the patch to see if it works. This
message to the linux-raid list has garnered no response, mostly because I
think everyone else on this list got it and thought to themselves, "huh?
what is this about? [delete]"...
Micah
On Thu, 19 Oct 2000, Marcelo Tosatti wrote:
>
> On Thu, 19 Oct 2000, Alan Cox wrote:
>
> > - Get to the bottom of the VM mystery if possible
>
> The RAID problem (which is caused by VM changes) is the same deadlock
> found in drbd and nbd.
>
> It was not a problem with kernels < 2.2.17 because there was no write
> throttling in shrink_mmap.
>
> I'm attaching "raid-0.90-2.2.17.patch" and "raid-2.2.17.patch". They
> should fix, respectively, raid 0.90 and stock 2.2.17 raid.
>
> I haven't tested the patches.
>
>
>
> --- linux/drivers/block/raid1.c.orig Thu Oct 19 18:18:25 2000
> +++ linux/drivers/block/raid1.c Thu Oct 19 18:48:46 2000
> @@ -40,7 +40,7 @@
> * simply can not afford to fail an allocation because
> * there is no failure return path (eg. make_request())
> */
> - while (!(ptr = kmalloc (sizeof (raid1_conf_t), GFP_KERNEL)))
> + while (!(ptr = kmalloc (sizeof (raid1_conf_t), GFP_BUFFER)))
> printk ("raid1: out of memory, retrying...\n");
>
> memset(ptr, 0, size);
> --- linux/drivers/block/raid1.c.orig Thu Oct 19 19:03:16 2000
> +++ linux/drivers/block/raid1.c Thu Oct 19 19:03:03 2000
> @@ -209,7 +209,7 @@
> PRINTK(("raid1_make_request().\n"));
>
> while (!( /* FIXME: now we are rather fault tolerant than nice */
> - r1_bh = kmalloc (sizeof (struct raid1_bh), GFP_KERNEL)
> + r1_bh = kmalloc (sizeof (struct raid1_bh), GFP_BUFFER)
> ) )
> {
> printk ("raid1_make_request(#1): out of memory\n");
> @@ -301,7 +301,7 @@
> * of this function to grok the difference ;)
> */
> while (!( /* FIXME: now we are rather fault tolerant than nice */
> - mirror_bh[i] = kmalloc (sizeof (struct buffer_head), GFP_KERNEL)
> + mirror_bh[i] = kmalloc (sizeof (struct buffer_head), GFP_BUFFER)
> ) )
> {
> printk ("raid1_make_request(#2): out of memory\n");
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Oct 23 2000 - 21:00:21 EST