[PATCH] Fix bug: BIO_RW_BARRIER requests to md/raid1 hang.

[NeilBrown]

The following fixes a rather embarassing bug in 2.6.16, and so should
go into 2.6.16.1, and 2.6.16-rc1.
Thanks,
NeilBrown


### Comments for Changeset

Both R1BIO_Barrier and R1BIO_Returned are 4 

This means that barrier requests don't get returned (i.e. b_endio
called) because it looks like they already have been.


Signed-off-by: Neil Brown <[EMAIL PROTECTED]>

### Diffstat output
 ./include/linux/raid/raid1.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff ./include/linux/raid/raid1.h~current~ ./include/linux/raid/raid1.h
--- ./include/linux/raid/raid1.h~current~   2006-03-23 13:46:27.0 
+1100
+++ ./include/linux/raid/raid1.h2006-03-23 14:36:53.0 +1100
@@ -130,6 +130,6 @@ struct r1bio_s {
  * with failure when last write completes (and all failed).
  * Record that bi_end_io was called with this flag...
  */
-#defineR1BIO_Returned 4
+#defineR1BIO_Returned 6
 
 #endif
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: naming of md devices

[Daniel Pittman]

Nix <[EMAIL PROTECTED]> writes:
> On 22 Mar 2006, Dan Christensen prattled cheerily:

[...]

> Last I heard the Debian initramfs constructs RAID arrays by explicitly
> specifying the devices that make them up. This is, um, a bad idea: the
> first time a disk fails or your kernel renumbers them you're in
> *trouble*.

The initrd tool, which was the default option, does this, and it is a
bad idea.

The initramfs tool, which is mostly shared with Ubuntu, is less stupid.
It uses mdadm and a loop to scan through the devices found on the
machine and find what RAID levels are required, then builds the RAID
arrays with mdrun.

Unfortunately, it still doesn't transfer /etc/mdadm.conf to the
initramfs, resulting in arrays changing position when constructed, to my
annoyance.   So, stupid, but not as stupid as the oldest tools.

Daniel
-- 
Digital Infrastructure Solutions -- making IT simple, stable and secure
Phone: 0401 155 707email: [EMAIL PROTECTED]

-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: naming of md devices

[Dan Christensen]

Dan Christensen writes:

> I currently use kernel autodetection of my raid devices.  I'm finding
> that if I use a stock Debian kernel versus a self-compiled kernel
> (2.6.15.6), the arrays md0 and md1 are switched, which creates a
> problem mounting my root filesystem.
> 
> Is there a way to make the names consistent?
>
> I'm happy to get rid of kernel autodetection and instead use
> mdadm.conf.  Is this just a matter of changing the partition types?
> Or a kernel boot parameter?  

To answer myself, the boot parameter raid=noautodetect is supposed
to turn off autodetection.  However, it doesn't seem to have an
effect with Debian's 2.6.16 kernel.  It does disable autodetection
for my self-compiled kernel, but since that kernel has no initrd or
initramfs, it gets stuck at that point.  [If I understand correctly,
you can't use mdadm for building the array without an initrd/ramfs.]

I also tried putting root=LABEL=/ on my boot command line.  Debian's
kernel seemed to understand this but gave:

Begin: Waiting for root filesystem...
Done.
Done.
Begin: Mounting root filesystem
...kernel autodetection of raid seemed to happen here...
ALERT /dev/disk/by_label// does not exist

> Will the Debian kernel/initramfs fall
> back to using mdadm to build the arrays?

dean gaudet <[EMAIL PROTECTED]> writes:

> On Thu, 23 Mar 2006, Nix wrote:
>
>> Last I heard the Debian initramfs constructs RAID arrays by explicitly
>> specifying the devices that make them up. This is, um, a bad idea:
>> the first time a disk fails or your kernel renumbers them you're
>> in *trouble*.
>
> yaird seems to dtrt ... at least in unstable

I might try this, but I'm still stuck without an easy way to turn
off auto-detection.

> the above is on unstable... i don't use stable (and stable definitely does 
> the wrong thing -- 
> ).

That bug is against initrd-tools, which is a different package I
believe.

For now, I've just put root=/dev/md1 on the Debian kernel boot line,
and root=/dev/md0 on my self-compiled boot line.


BUT, my self-compiled kernel is now failing to bring up the arrays!  I
didn't change anything on the arrays or on this kernel's boot line,
and I have not turned off kernel auto-detection, so I have no idea why
there is a problem.  Unfortunately, I don't have a serial console, and
the kernel panics so I can't scroll back to see the relevant part of
the screen.  My self-compiled kernel has everything needed for
my root filesystem compiled in, so I avoided needing an initramfs.

If I'm able to get my tuner card, etc working with Debian's kernel,
then I won't need my self-compiled kernel anymore, but it's
disconcerting that I now can't boot a kernel that worked fine a few
hours ago...  Any ideas what could have happened?

Thanks for the help so far!

Dan

-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Large Stripe Size (>4MB)

[Neil Brown]

On Wednesday March 22, [EMAIL PROTECTED] wrote:
> Paul M.  gpmidi.net> writes:
> 
> > 
> > Couple questions related to some raid using some firewire disks:
> > 
> > Is it possible to set the stripe size to 16+MB?
> > 
> > Is there a way to force the raid driver to only access one disk at a time?
> > 
> > Thanks,
> > 
> > Paul
> 
> Yes, it's possible - just change the #define MAX_CHUNK_SIZE 
> in linux/include/linux/raid/md_k.h and rebuild your kernel.  I am 
> happily running an array with a 64MB chunk.
> 
> Can some knowledgeable person explain if there is any downside to a very large
> number in that define (as in, a few GB)?  Does it use up any resources or can 
> it
> overflow any arithmetic somewhere in the kernel?

Up to 2Gig should work without problems.  More than that will cause
overflow in the 0.90 superblock.  With the version-1 superblock we
should be able to support chunks upto a terrabyte (I think) but we
would need a code-audit and a fair bit of fixing first.

NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: naming of md devices

[dean gaudet]

On Thu, 23 Mar 2006, Nix wrote:

> Last I heard the Debian initramfs constructs RAID arrays by explicitly
> specifying the devices that make them up. This is, um, a bad idea:
> the first time a disk fails or your kernel renumbers them you're
> in *trouble*.

yaird seems to dtrt ... at least in unstable.  if you install yaird 
instead of initramfs-tools you get stuff like this in the initrd /init:

mknod /dev/md3 b 9 3
mdadm -Ac partitions /dev/md3 --uuid 2b3a5b77:c7b4ab81:a2b8322a:db5c4e88

initramfs-tools also appears to do something which should work... but i 
haven't tested it... it basically runs "mdrun /dev" without specifying a 
minor/uuid for the root, so it'll start all arrays... i'm afraid that 
might mess up for one of my arrays which is "auto=mdp"... and has the 
annoying property of starting arrays on disks you've moved from other 
systems.

so anyhow i lean towards yaird at the moment... (and i should submit some 
bug reports i guess).

the above is on unstable... i don't use stable (and stable definitely does 
the wrong thing -- 
).

-dean
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: naming of md devices

[Nix]

On 22 Mar 2006, Dan Christensen prattled cheerily:
> I currently use kernel autodetection of my raid devices.  I'm finding
> that if I use a stock Debian kernel versus a self-compiled kernel
> (2.6.15.6), the arrays md0 and md1 are switched, which creates a
> problem mounting my root filesystem.
> 
> Is there a way to make the names consistent?

Well, you could stack LVM atop it ;)

but yes, there is. THis is my mdadm.conf:

DEVICE partitions
ARRAY /dev/md0 UUID=3a51b74f:8a759fe7:8520304c:3adbceb1
ARRAY /dev/md1 UUID=a5a6cad4:2c7fdc07:88a409b9:192ed3bf
ARRAY /dev/md2 UUID=fe44916d:a1098576:8007fb81:2ee33b5a

In fact I don't care what's mounted where because all of these that are
necessary for booting are an LVM volume group, and vgscan takes care
of everything: but if you arrange to use the mdadm.conf, you're safe.

(You can use the RAID array name, as well, but if you don't have
a name I'm not sure if you can assign a new one, while every array
always has a UUID.)

I'm not sure if there's a way to specify this on the kernel command line
when using kernel autodetection: I've never used it. (Neil? Anyone?)

> I'm happy to get rid of kernel autodetection and instead use
> mdadm.conf.  Is this just a matter of changing the partition types?
> Or a kernel boot parameter?  Will the Debian kernel/initramfs fall
> back to using mdadm to build the arrays?

Last I heard the Debian initramfs constructs RAID arrays by explicitly
specifying the devices that make them up. This is, um, a bad idea:
the first time a disk fails or your kernel renumbers them you're
in *trouble*.

-- 
`Come now, you should know that whenever you plan the duration of your
 unplanned downtime, you should add in padding for random management
 freakouts.'
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: raid5 that used parity for reads only when degraded

[Neil Brown]

On Wednesday March 22, [EMAIL PROTECTED] wrote:
> Hello,
> 
> I have a question: I'd like to have a raid5 array which writes parity data but
> does not check it during reads while the array is ok.  I would trust each disk
> to detect errors itself and cause the array to be degraded if necessary, in
> which case that disk would drop out and the parity data would start being used
> just as in a normal raid5.  In other words until there is an I/O error that
> causes a disk to drop out, such an array would behave almost like a raid0 with
> N-1 disks as far as reads are concerned.  Ideally this behavior would be
> something that one could turn on/off on the fly with a ioctl or via a echo 
> "0" >
> /sys/block/md0/check_parity_on_reads type of mechanism.  
> 
> How hard is this to do?   Is anyone interested in helping to do this?  I think
> it would really help applications which have a lot more reads than writes. 
> Where exactly does parity checking during reads happen?  I've looked over the
> code briefly but the right part of it didn't appear obvious ;)

Parity checking does not happen during read.  You already have what
you want.

NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

raid5 that used parity for reads only when degraded

[Alex Izvorski]

Hello,

I have a question: I'd like to have a raid5 array which writes parity data but
does not check it during reads while the array is ok.  I would trust each disk
to detect errors itself and cause the array to be degraded if necessary, in
which case that disk would drop out and the parity data would start being used
just as in a normal raid5.  In other words until there is an I/O error that
causes a disk to drop out, such an array would behave almost like a raid0 with
N-1 disks as far as reads are concerned.  Ideally this behavior would be
something that one could turn on/off on the fly with a ioctl or via a echo "0" >
/sys/block/md0/check_parity_on_reads type of mechanism.  

How hard is this to do?   Is anyone interested in helping to do this?  I think
it would really help applications which have a lot more reads than writes. 
Where exactly does parity checking during reads happen?  I've looked over the
code briefly but the right part of it didn't appear obvious ;)

Regards,
--Alex


-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Large Stripe Size (>4MB)

[Alex Izvorski]

Paul M.  gpmidi.net> writes:

> 
> Couple questions related to some raid using some firewire disks:
> 
> Is it possible to set the stripe size to 16+MB?
> 
> Is there a way to force the raid driver to only access one disk at a time?
> 
> Thanks,
> 
> Paul

Yes, it's possible - just change the #define MAX_CHUNK_SIZE 
in linux/include/linux/raid/md_k.h and rebuild your kernel.  I am 
happily running an array with a 64MB chunk.

Can some knowledgeable person explain if there is any downside to a very large
number in that define (as in, a few GB)?  Does it use up any resources or can it
overflow any arithmetic somewhere in the kernel?

The original 4MB max limit and 64k default in mdadm appears to be based on the
(erroneous) assumption that small chunks always provide better performance, but
that *really* depends on the application.  I would say that there are two ways
in which high performance can be achieved, both based on minimizing the number
of seeks per transaction or per unit of throughput: either a chunk size much
smaller than the typical read size (so all heads seek to the same place and then
read a bunch from there), or a chunk size much larger than the typical read, and
a lot of concurrent reads (so each read is typically serviced by only a single
seek on one drive, but all drives are kept busy).

--Alex


--- linux.orig/include/linux/raid/md_k.h2006-03-22 16:42:49
+++ linux/include/linux/raid/md_k.h 2006-03-21 15:04:38
@@ -83,7 +83,7 @@
  * options passed in raidrun:
  */

-#define MAX_CHUNK_SIZE (4096*1024)
+#define MAX_CHUNK_SIZE (128*1024*1024)

 /*
  * MD's 'extended' device


-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux MD RAID5/6 bitmap patches

[Paul Clements]

Yogesh Pahilwan wrote:


Thanks for your reply. As far as what I understood that when we apply the
bitmap patch, for every write it will do 2 sync writes that is setting the
dirty bit, writing intent log and one async write for clearing the dirty
bit. Is it correct?


The bits are in the intent log, so the "setting dirty bit" and "writing 
intent log" are the same thing. Just one write.



If that is the case are there any patches available which can do collection
of sync write in a queue and write a collection in single write request.
For Eg:
For 10 writes , we will have 10 + 1 sync writes + 10 async write.


The bitmap code already does this by default. The bitmap writes are 
queued up so that all writes to a given page (within a short time 
period) are reduced to a single write. The performance is actually quite 
good. There's very little performance difference between having a bitmap 
versus not having one.



I mean to say , 10 sync writes for setting the dirty bits + 1 sync write for
write intent log for all queued request in one write operation + 10 async
write for clearing the dirty bit.


The async writes for clearing the bitmap are also combined.

--
Paul
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

naming of md devices

[Dan Christensen]

I currently use kernel autodetection of my raid devices.  I'm finding
that if I use a stock Debian kernel versus a self-compiled kernel
(2.6.15.6), the arrays md0 and md1 are switched, which creates a
problem mounting my root filesystem.

Is there a way to make the names consistent?

I'm happy to get rid of kernel autodetection and instead use
mdadm.conf.  Is this just a matter of changing the partition types?
Or a kernel boot parameter?  Will the Debian kernel/initramfs fall
back to using mdadm to build the arrays?

Thanks for any help,

Dan

-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

raid5: switching cache buffer size, 512 --> 4096

[Shai]

FYI

-- Forwarded message --
From: Shai
Date: Mar 22, 2006 6:27 PM
Subject: Re: raid5: switching cache buffer size, 512 --> 4096
To: Gordon H.

Hi,

I want to thank you very much for answering all my questions and I
don't want you to think for one second that I don't appricitate your
time... I do :)

Ok, so getting them removed via the source is the solution.. but what
if I don't have the source? Can you tell me what exactly I should look
for and change?

Thanks (again),
Shai

On 3/22/06, Gordon H. wrote:
> On Wed, 22 Mar 2006, Shai wrote:
>
> > Ok,
> >
> > say I don't care about md1 being redone. Is there anything i can do to
> > it that will fix these error messages? format again with some
> > parameters? rebuild the raid?
>
> They asren't really errors - more informational. Which is why you should
> comment them out of the source code if you don't want them...
>
> You aer probably taking a performance hit when they are printed though -
> for 2 reasons, one the overhead of actually printing them (and logging
> them), and the other when the cache is flushed, so best to stop it
> happening, so look in the xfs manuals to see if you can fix the blocks
> size on the journal.
>
>  Gordon
>
>
> >
> > Shai
> >
> > On 3/22/06, Gordon H. wrote:
> > > On Wed, 22 Mar 2006, Shai wrote:
> > >
> > > > I just found this email on the website but I don't know where the 
> > > > archives are.
> > > > I'm not very good with mdadm and I don't want to mess things up to
> > > > much trying things out.
> > >
> > > It's got nothing to do with mdadm - it's simply that xfs sometiems makes a
> > > request for a block-size of 512 bytes, then a block size of 4096 bytes,
> > > and theres only one block cache in the md system, so when the block size
> > > changes it has to flush the cache.
> > >
> > > > Can you show me the archives?
> > >
> > > http://www.google.co.uk/search?hl=en&q=linux-raid+archive&btnG=Google+Search&meta=
> > >
> > > > Can you maybe help me out in finding how to fix it rather then comment
> > > > out the error messages?
> > >
> > > If you can fix it, then the linux-raid crowd will welcome you with open
> > > arms :)
> > >
> > > But I'd start with looking at the man pages for xfs and seeing if theres a
> > > way to fix the block size of the journal.
> > >
> > > Gordon
> > >
> > >
> > > > Thanks in advance!!!
> > > >
> > > > Shai
> > > >
> > > > On 3/22/06, Gordon H. wrote:
> > > > > On Wed, 22 Mar 2006, Shai wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I have two raid5 MDs: /dev/md0 and /dev/md1;
> > > > > >
> > > > > > I had broken md0 the other day and had to rebuild it.
> > > > > > i've formated it as xfs and wanted to make md1 also xfs so I 
> > > > > > decided to
> > > > > > move all the data from md1 to md0.
> > > > > >
> > > > > > while doing the cp of all that data, I'm getting lots of messages on
> > > > > > the console screen which don't enable me to work on it ( i use 
> > > > > > telnet
> > > > > > now ):
> > > > > >
> > > > > > > raid5: switching cache buffer size, 512 --> 4096
> > > > > > > raid5: switching cache buffer size, 4096 --> 512
> > > > > >
> > > > > > Can someone help me resolve this?
> > > > >
> > > > > Search the archives - I had this many moons ago. It's something to do 
> > > > > with
> > > > > xfs using a different block-size for the journal to the data, and I 
> > > > > think
> > > > > there are mount/mkfs options to remedy this, or the other solution is 
> > > > > to
> > > > > find the kprintf in the driver and comment it out...
> > > > >
> > > > > (I stopped uing xfs, but not for other reasons. don't see it under 
> > > > > ext3)
> > > > >
> > > > > Gordon
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Does grub support sw raid1?

[Bill Davidsen]

Mike Hardy wrote:


This works for me, there are several pages out there (I recall using the
commands from a gentoo one most recently) that show the exact sequence
of grub things you should do to get grub in the MBR of both disks.

It sounds like your machine may not be set to boot off of anything other
than that one disk though? Is that maybe a BIOS thing?

I dunno, but I have definitely pulled a primary drive out of the system
completely and booted off the second one, then had linux come up with
(correctly) degraded arrays
 



Frequently a BIOS will boot a 2nd drive if the first is missing/dead, 
but not if it returns bad data (CRC error). A soft fail is not handled 
correctly by all BIOS' in use, possibly a majority of them.



-Mike

Herta Van den Eynde wrote:
 


(crossposted to linux-raid@vger.kernel.org and redhat-list@redhat.com)
(apologies for this, but this should have be operational last week)

I installed Red Hat EL AS 4 on a HP Proliant DL380, and configured all
system devices in software RAID 1.  I added an entry to grub.conf to
fallback to the second disk in case the first entry fails.  At boottime,
booting from hd0 works fine.  As does booting from hd1.

Until I physically remove hd0 from the system.

I tried manually installing grub on hd1,
I added hd1 to the device.map and subsequently re-installed grub on it,
I remapped hd0 to /dev/cciss/c0d1 and subsequently re-installed grub
all to no avail.

I previously installed this while the devices were in slots 2 and 3. The
system wouldn't even boot then.  It looks as though booting from sw
RAID1 will only work when there's a valid device in slot 0.  Still
preferable over hw RAID1, but even better would be if this worked all
the way.

Is this working for anyone?  Any idea what I may have overlooked?  Any
suggestions on how to debug this?

Kind regards,

Herta

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm



--
bill davidsen <[EMAIL PROTECTED]>
 CTO TMR Associates, Inc
 Doing interesting things with small computers since 1979

-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: raid5 performance question

[Bill Davidsen]

Neil Brown wrote:


On Tuesday March 7, [EMAIL PROTECTED] wrote:
 


Neil.
what is the stripe_cache exacly ?
   



In order to ensure correctness of data, all IO operations on a raid5
pass through the 'stripe cache'  This is a cache of stripes where each
stripe is one page wide across all devices.

e.g. to write a block, we allocate one stripe in the cache to cover
that block, pre-read anything that might be needed, copy in the new
data and update parity, and write out anything that has changed.
 

I can see that you would have to read the old data and parity blocks for 
RAID-5, I assume that's what you mean by "might be needed" and not a 
read of every drive to get the data to rebuild the parity from scratch. 
That would be not only slower, but require complex error recovery on an 
error reading unneeded data.



Similarly to read, we allocate a stripe to cover the block, read in
the requires parts, and copy out of the stripe cache into the
destination.

Requiring all reads to pass through the stripe cache is not strictly
necessary, but it keeps the code a lot easier to manage (fewer special
cases).   Bypassing the cache for simple read requests when the array
is non-degraded is on my list

It sounds as if you do a memory copy with each read, even if a read to 
user buffer would be possible. Hopefully I'm reading that wrong.


--
bill davidsen <[EMAIL PROTECTED]>
 CTO TMR Associates, Inc
 Doing interesting things with small computers since 1979

-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: raid5: switching cache buffer size, 512 --> 4096

[Gordon Henderson]

On Wed, 22 Mar 2006, Shai wrote:

> Hi,
>
> I have two raid5 MDs: /dev/md0 and /dev/md1;
>
> I had broken md0 the other day and had to rebuild it.
> i've formated it as xfs and wanted to make md1 also xfs so I decided to
> move all the data from md1 to md0.
>
> while doing the cp of all that data, I'm getting lots of messages on
> the console screen which don't enable me to work on it ( i use telnet
> now ):
>
> > raid5: switching cache buffer size, 512 --> 4096
> > raid5: switching cache buffer size, 4096 --> 512
>
> Can someone help me resolve this?

Search the archives - I had this many moons ago. It's something to do with
xfs using a different block-size for the journal to the data, and I think
there are mount/mkfs options to remedy this, or the other solution is to
find the kprintf in the driver and comment it out...

(I stopped uing xfs, but not for other reasons. don't see it under ext3)

Gordon
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

raid5: switching cache buffer size, 512 --> 4096

[Shai]

Hi,

I have two raid5 MDs: /dev/md0 and /dev/md1;

I had broken md0 the other day and had to rebuild it.
i've formated it as xfs and wanted to make md1 also xfs so I decided to
move all the data from md1 to md0.

while doing the cp of all that data, I'm getting lots of messages on
the console screen which don't enable me to work on it ( i use telnet
now ):

> raid5: switching cache buffer size, 512 --> 4096
> raid5: switching cache buffer size, 4096 --> 512

Can someone help me resolve this?

Thanks,
Shai
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: a user-raid list for non gurus?

[Bill Davidsen]

Sandro Dentella wrote:


Hi all,

 even thought I'm subscribed to this list since quite a lot of time, I only
 can grab a little purcentage of the discussion due to technical gap.
 
 When it happens that I ask something to the list I normally get unanswered

 even on problems that in my opinion shouldn't be considered really
 specific to my setup. Here just the last 2 questions:

http://marc.theaimsgroup.com/?l=linux-raid&m=114185900020437&w=2
http://marc.theaimsgroup.com/?l=linux-raid&m=114120476328121&w=2
 
 I'd like to know if there is a users-linux-raid where these kind of

 questions get answered, if I should just insist on this list, or if I
 missed some document (possibly a complete howto) that already gives 
 thorought info on how to cope with troubles, or a wiki.
 



The problem is that with a user list, the people who are best able to 
answer your questions are unlikely to see them. While many people have 
good intentions, in practice we lack TIME to read yet another list, 
particularly those where the chance of finding something useful to an 
experienced user are small.


 
 I feel like linux-raid is missing a good howto. The documentation you can

 find is often outdated or incomplete and it only saldomly helped me to get
 out of problems. 
 



Right now RAID is moving so fast that it would be out of date, and 
that's less helpful than nothing. The mdadm man page is the howto, and 
the only thing remotely able to provide information on exactly what you 
have installed today.



 The sad part of all this is that with raid systems you are not normally in
 the mood/position to test things. You would much more prefere to arrive at
 the crash already with the knowledge on how to cope with it... but the
 crash is never as the one you simulated failing the device...

Thanks for your attention and you job anyhow
sandro
*:-)


PS: In case anybody feeels like writing a complete howto I could
   help... with the index ;-) of what a system admin -not a raid guru-
   would like to read to understant raid (not just to setup)
 


I agree that people don't feel like messing with their RAID when they have it 
working! I would love to change my setup, but there is no funding for a backup 
system to make backing up several TB convenient, and no time to spend doing it 
the hard way.

--
bill davidsen <[EMAIL PROTECTED]>
 CTO TMR Associates, Inc
 Doing interesting things with small computers since 1979

-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: Linux MD RAID5/6 bitmap patches

[Yogesh Pahilwan]

Hi Neil,

Thanks for your reply. As far as what I understood that when we apply the
bitmap patch, for every write it will do 2 sync writes that is setting the
dirty bit, writing intent log and one async write for clearing the dirty
bit. Is it correct?
If that is the case are there any patches available which can do collection
of sync write in a queue and write a collection in single write request.
For Eg:
For 10 writes , we will have 10 + 1 sync writes + 10 async write.
I mean to say , 10 sync writes for setting the dirty bits + 1 sync write for
write intent log for all queued request in one write operation + 10 async
write for clearing the dirty bit.

So as we reducing the sync write request by using collections will it
improve the performance and any patches available which follows this
approach.

Thanks and Regards
Yogesh

-Original Message-
From: Neil Brown [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, March 22, 2006 3:36 PM
To: Yogesh Pahilwan
Cc: linux-raid@vger.kernel.org
Subject: Re: Linux MD RAID5/6 bitmap patches

On Wednesday March 22, [EMAIL PROTECTED] wrote:
> Hello,
> 
> I want to know where I can get various MD RAID5/RAID6 bitmap patches for
> linux kernel 2.6.15.

2.6.15 already includes support for bitmaps for MD raid5 and raid6
(And raid1).  No patches needed.

> I want to know what kind of performance optimization possible on bitmap
> patches. I also want to know are 
> there any patches available which provides performance optimizations using
> bitmaps. 

Bitmaps optimise rebuild time after a crash, or after removing and
re-adding a device.  They do not improve normal read/write
performance, and may well cause a small degradation in performance.

NeilBrown

-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Linux MD RAID5/6 bitmap patches

[Neil Brown]

On Wednesday March 22, [EMAIL PROTECTED] wrote:
> Hello,
> 
> I want to know where I can get various MD RAID5/RAID6 bitmap patches for
> linux kernel 2.6.15.

2.6.15 already includes support for bitmaps for MD raid5 and raid6
(And raid1).  No patches needed.

> I want to know what kind of performance optimization possible on bitmap
> patches. I also want to know are 
> there any patches available which provides performance optimizations using
> bitmaps. 

Bitmaps optimise rebuild time after a crash, or after removing and
re-adding a device.  They do not improve normal read/write
performance, and may well cause a small degradation in performance.

NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html