[PATCH md 000 of 2] Introduction

[PATCH md 000 of 2] Introduction

[NeilBrown]

Two patches against 2.6.12-rc2 for md.
(patches apply to 2.6.12-rc2-mm1 with various offsets).

The first closes an extreme small race in md thread deregistration.
This race was actually lost by someone who, due to a different bug
which has since been fixed, has md threads being created and destroyed
at a very high rate.

The second removes a number of MD_BUG calls that that are either
completely pointless, or misleading (i.e. the report a bug when it is
just an unusual condition that is handled correctly).

NeilBrown


 [PATCH md 001 of 2] Close a small race in md thread deregistration
 [PATCH md 002 of 2] Remove a number of misleading calls to MD_BUG

[PATCH md 000 of 2] Introduction

[NeilBrown]

Hi again,
 two more patches for md follow.  Both raid1 related.
 These are happy to sit in the queue for after 2.6.12.

Thanks,
NeilBrown

 [PATCH md 001 of 2] Cause md/raid1 to "repack" working devices when number of drives is changed.
 [PATCH md 002 of 2] Make sure recovery happens when add_new_disk is used for hot_add

[PATCH md 000 of 2] Introduction

[NeilBrown]

Following are two very trivial patches against 2.6.13-rc6.
If 2.6.13 is still open for such trivial fixes, it would be good for
them to go in, but if not, I won't loose any sleep over it.

The first arranges that the first open of /dev/mdX will auto-load the
md modules (I don't know when that functionality disappeared).
The second fixes a possibly problem where-by if you stop an array and
create a new one on the same md device, it might not start any resync
that might be needed.

Thanks,
NeilBrown


 [PATCH md 001 of 2] Create a MODULE_ALIAS for md corresponding to it's block major number.
 [PATCH md 002 of 2] Clear the 'recovery' flags when starting an md array.

[PATCH md 000 of 2] Introduction

[NeilBrown]

Two patches for md in 2.6.14-rc5-mm1 (First one depends on -mm stuff,
second should apply to most recent 2.6 kernels).

I'd like to review the sysfs a bit more before it goes to Linus, but
the rest can go anytime.
Thanks,
NeilBrown


 [PATCH md 001 of 2] Remove attempt to use dynamic names in sysfs for component devices on an MD array.
 [PATCH md 002 of 2] Allow md arrays to be started read-only (module parameter).

Re: [PATCH md 000 of 2] Introduction

[Neil Brown]

On Sunday October 30, akpm@osdl.org wrote:
> NeilBrown <neilb@suse.de> wrote:
> >
> > 
> >  I'd like to review the sysfs a bit more before it goes to Linus, but
> >  the rest can go anytime.
> 
> umm, what does "the sysfs" refer to?

Sorry.. "the sysfs related patches".

Those marked as 'THIS' below.  

However I think a couple that come after those won't simple move
backwards (largely due to
md-convert-faulty-and-in_sync-fields-to-bits-in-flags-field).

I'll make sure you have a full set that I am happy to go to Linus by
the end of the week.

Thanks,
NeilBrown


> 
> Current md patches in -mm:
> 
> md-better-handling-of-readerrors-with-raid5.patch
THIS > md-initial-sysfs-support-for-md.patch
THIS > md-extend-md-sysfs-support-to-component-devices.patch
THIS > md-add-kobject-sysfs-support-to-raid5.patch
THIS > md-allow-a-manual-resync-with-md.patch
THIS > md-teach-raid5-the-difference-between-check-and-repair.patch
> md-provide-proper-rcu_dereference--rcu_assign_pointer-annotations-in-md.patch
THIS > md-fix-ref-counting-problems-with-kobjects-in-md.patch
THIS > md-minor-md-fixes.patch
THIS > md-change-raid5-sysfs-attribute-to-not-create-a-new-directory.patch
> md-improvements-to-raid5-handling-of-read-errors.patch
> md-convert-faulty-and-in_sync-fields-to-bits-in-flags-field.patch
> md-make-md-on-disk-bitmaps-not-host-endian.patch
> md-support-bio_rw_barrier-for-md-raid1.patch
> drivers-md-fix-up-schedule_timeout-usage.patch
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH md 000 of 2] Introduction

[Andrew Morton]

NeilBrown <neilb@suse.de> wrote:
>
> 
>  I'd like to review the sysfs a bit more before it goes to Linus, but
>  the rest can go anytime.

umm, what does "the sysfs" refer to?

Current md patches in -mm:

md-better-handling-of-readerrors-with-raid5.patch
md-initial-sysfs-support-for-md.patch
md-extend-md-sysfs-support-to-component-devices.patch
md-add-kobject-sysfs-support-to-raid5.patch
md-allow-a-manual-resync-with-md.patch
md-teach-raid5-the-difference-between-check-and-repair.patch
md-provide-proper-rcu_dereference--rcu_assign_pointer-annotations-in-md.patch
md-fix-ref-counting-problems-with-kobjects-in-md.patch
md-minor-md-fixes.patch
md-change-raid5-sysfs-attribute-to-not-create-a-new-directory.patch
md-improvements-to-raid5-handling-of-read-errors.patch
md-convert-faulty-and-in_sync-fields-to-bits-in-flags-field.patch
md-make-md-on-disk-bitmaps-not-host-endian.patch
md-support-bio_rw_barrier-for-md-raid1.patch
drivers-md-fix-up-schedule_timeout-usage.patch

Re: [PATCH md 000 of 2] Introduction

[Andrew Morton]

Neil Brown <neilb@suse.de> wrote:
>
> On Sunday October 30, akpm@osdl.org wrote:
> > NeilBrown <neilb@suse.de> wrote:
> > >
> > > 
> > >  I'd like to review the sysfs a bit more before it goes to Linus, but
> > >  the rest can go anytime.
> > 
> > umm, what does "the sysfs" refer to?
> 
> Sorry.. "the sysfs related patches".
> 
> Those marked as 'THIS' below.  
> 
> However I think a couple that come after those won't simple move
> backwards (largely due to
> md-convert-faulty-and-in_sync-fields-to-bits-in-flags-field).
> 
> I'll make sure you have a full set that I am happy to go to Linus by
> the end of the week.

hm, OK, that's a bit late in the process to be introducing new material, so
no later please.

Also, please make sure that Greg is copied on sysfs things - save me an
email ;)

Re: [PATCH md 000 of 2] Introduction

[Mr. James W. Laferriere]

	Hello Neil ,  The original '[PATCH md 000 of 2] Introduction' never hit 
	the list afaict .  Could you please re-send or if you did & only I am 
	without it send privately .  Tia ,  JimL

On Mon, 31 Oct 2005, Neil Brown wrote:
> On Sunday October 30, akpm@osdl.org wrote:
> > NeilBrown <neilb@suse.de> wrote:
> > >  I'd like to review the sysfs a bit more before it goes to Linus, but
> > >  the rest can go anytime.
> > umm, what does "the sysfs" refer to?
> Sorry.. "the sysfs related patches".
> Those marked as 'THIS' below.  
> However I think a couple that come after those won't simple move
> backwards (largely due to
> md-convert-faulty-and-in_sync-fields-to-bits-in-flags-field).
> I'll make sure you have a full set that I am happy to go to Linus by
> the end of the week.
> Thanks,
> NeilBrown
> > Current md patches in -mm:
> > md-better-handling-of-readerrors-with-raid5.patch
> THIS > md-initial-sysfs-support-for-md.patch
> THIS > md-extend-md-sysfs-support-to-component-devices.patch
> THIS > md-add-kobject-sysfs-support-to-raid5.patch
> THIS > md-allow-a-manual-resync-with-md.patch
> THIS > md-teach-raid5-the-difference-between-check-and-repair.patch
> > md-provide-proper-rcu_dereference--rcu_assign_pointer-annotations-in-md.patch
> THIS > md-fix-ref-counting-problems-with-kobjects-in-md.patch
> THIS > md-minor-md-fixes.patch
> THIS > md-change-raid5-sysfs-attribute-to-not-create-a-new-directory.patch
> > md-improvements-to-raid5-handling-of-read-errors.patch
> > md-convert-faulty-and-in_sync-fields-to-bits-in-flags-field.patch
> > md-make-md-on-disk-bitmaps-not-host-endian.patch
> > md-support-bio_rw_barrier-for-md-raid1.patch
> > drivers-md-fix-up-schedule_timeout-usage.patch
-- 
+------------------------------------------------------------------+
| James   W.   Laferriere | System    Techniques | Give me VMS     |
| Network        Engineer | 3542 Broken Yoke Dr. |  Give me Linux  |
| babydr@baby-dragons.com | Billings , MT. 59105 |   only  on  AXP |
+------------------------------------------------------------------+

Re: [PATCH md 000 of 2] Introduction

[Neil Brown]

On Monday October 31, babydr@baby-dragons.com wrote:
> 	Hello Neil ,  The original '[PATCH md 000 of 2] Introduction' never hit 
> 	the list afaict .  Could you please re-send or if you did & only I am 
> 	without it send privately .  Tia ,  JimL

I cannot knot who else is without it :-), but you can find it here.


http://marc.theaimsgroup.com/?l=linux-raid&m=113073839213484&w=2


NeilBrown

[PATCH md 000 of 2] Introduction

[NeilBrown]

Following are two patches for md in 2.6.14-mm2 that are suitable to go
into the 2.6.15-rc series.

The first adds a date to the deprecation of START_ARRAY ioctl.

The second fixes a recently introduced problem that causes md threads
to permanently add to the load average (other than that, every works
fine).

 [PATCH md 001 of 2] Mark START_ARRAY deprecated with a date.
 [PATCH md 002 of 2] Make md threads interruptible again.

[PATCH md 001 of 2] Mark START_ARRAY deprecated with a date.

[NeilBrown]

This was marked deprecated "after 2.6" back in the 2.5 days.  
But now it seems there isn't going to be any "after 2.6", and
we deprecate by date now.  So set a date.

Signed-off-by: Neil Brown <neilb@suse.de>

### Diffstat output
 ./Documentation/feature-removal-schedule.txt |    9 +++++++++
 ./drivers/md/md.c                            |    2 +-
 2 files changed, 10 insertions(+), 1 deletion(-)

diff ./Documentation/feature-removal-schedule.txt~current~ ./Documentation/feature-removal-schedule.txt
--- ./Documentation/feature-removal-schedule.txt~current~	2005-11-15 10:25:30.000000000 +1100
+++ ./Documentation/feature-removal-schedule.txt	2005-11-15 10:25:30.000000000 +1100
@@ -131,3 +131,12 @@ What:	EXPORT_SYMBOL(lookup_hash)
 When:	January 2006
 Why:	Too low-level interface.  Use lookup_one_len or lookup_create instead.
 Who:	Christoph Hellwig <hch@lst.de>
+
+---------------------------
+
+What:	START_ARRAY ioctl for md
+When:	July 2006
+Files:	drivers/md/md.c
+Why:	Not reliable by design - can fail when most needed.
+	Alternatives exist
+Who:	NeilBrown <neilb@suse.de>

diff ./drivers/md/md.c~current~ ./drivers/md/md.c
--- ./drivers/md/md.c~current~	2005-11-15 10:25:30.000000000 +1100
+++ ./drivers/md/md.c	2005-11-15 10:25:30.000000000 +1100
@@ -3156,7 +3156,7 @@ static int md_ioctl(struct inode *inode,
 		if (cnt > 0 ) {
 			printk(KERN_WARNING
 			       "md: %s(pid %d) used deprecated START_ARRAY ioctl. "
-			       "This will not be supported beyond 2.6\n",
+			       "This will not be supported beyond July 2006\n",
 			       current->comm, current->pid);
 			cnt--;
 		}

[PATCH md 002 of 2] Make md threads interruptible again.

[NeilBrown]

Despite the fact that md threads don't need to be signalled, and won't
respond to signals anyway, we need to have an 'interruptible' wait,
else they stay in 'D' state and add to the load average.

Signed-off-by: Neil Brown <neilb@suse.de>

### Diffstat output
 ./drivers/md/md.c |   17 +++++++++++++----
 1 file changed, 13 insertions(+), 4 deletions(-)

diff ./drivers/md/md.c~current~ ./drivers/md/md.c
--- ./drivers/md/md.c~current~	2005-11-15 10:25:30.000000000 +1100
+++ ./drivers/md/md.c	2005-11-15 10:28:30.000000000 +1100
@@ -3437,10 +3437,19 @@ static int md_thread(void * arg)
 	allow_signal(SIGKILL);
 	while (!kthread_should_stop()) {
 
-		wait_event_timeout(thread->wqueue,
-				   test_bit(THREAD_WAKEUP, &thread->flags)
-				   || kthread_should_stop(),
-				   thread->timeout);
+		/* We need to wait INTERRUPTIBLE so that
+		 * we don't add to the load-average.
+		 * That means we need to be sure no signals are
+		 * pending
+		 */
+		if (signal_pending(current))
+			flush_signals(current);
+
+		wait_event_interruptible_timeout
+			(thread->wqueue,
+			 test_bit(THREAD_WAKEUP, &thread->flags)
+			 || kthread_should_stop(),
+			 thread->timeout);
 		try_to_freeze();
 
 		clear_bit(THREAD_WAKEUP, &thread->flags);

Re: [PATCH md 002 of 2] Make md threads interruptible again.

[Andrew Morton]

NeilBrown <neilb@suse.de> wrote:
>
> 
> Despite the fact that md threads don't need to be signalled, and won't
> respond to signals anyway, we need to have an 'interruptible' wait,
> else they stay in 'D' state and add to the load average.
> 
> ...
> +		if (signal_pending(current))
> +			flush_signals(current);

Kernel threads don't accept signals by default, so the above is unneeded.

I'll leave it in there now, since that's how things used to be, but please
make a note to nuke that check, then test it to make sure I'm telling the
truth, then fix it up later on?

Re: [PATCH md 000 of 2] Introduction

[Mr. James W. Laferriere]

 	Hello Neil ,

On Tue, 15 Nov 2005, NeilBrown wrote:
> Following are two patches for md in 2.6.14-mm2 that are suitable to go
> into the 2.6.15-rc series.
>
> The first adds a date to the deprecation of START_ARRAY ioctl.
>
> The second fixes a recently introduced problem that causes md threads
> to permanently add to the load average (other than that, every works
> fine).
>
> [PATCH md 001 of 2] Mark START_ARRAY deprecated with a date.
> [PATCH md 002 of 2] Make md threads interruptible again.

> diff ./Documentation/feature-removal-schedule.txt~current~ /Documentation/feature-removal-schedule.txt
> --- ./Documentation/feature-removal-schedule.txt~current~       2005-11-15 10:25:30.000000000 +1100
> +++ ./Documentation/feature-removal-schedule.txt        2005-11-15 10:25:30.000000000 +1100
> @@ -131,3 +131,12 @@ What:      EXPORT_SYMBOL(lookup_hash)
>  When:  January 2006
>  Why:   Too low-level interface.  Use lookup_one_len or lookup_create instead.
>  Who:   Christoph Hellwig <hch@lst.de>
> +
> +---------------------------
> +
> +What:  START_ARRAY ioctl for md
> +When:  July 2006
> +Files: drivers/md/md.c
> +Why:   Not reliable by design - can fail when most needed.
> +       Alternatives exist
> +Who:   NeilBrown <neilb@suse.de>

 	Would some please update Documentation/md.txt with the alternates
 	that exist to replace START_ARRAY ?  Or for that matter any kernel
 	related document that covers the md driver &/or its tools .
 		Tia ,  JimL

-- 
+------------------------------------------------------------------+
| James   W.   Laferriere | System    Techniques | Give me VMS     |
| Network        Engineer | 3542 Broken Yoke Dr. |  Give me Linux  |
| babydr@baby-dragons.com | Billings , MT. 59105 |   only  on  AXP |
+------------------------------------------------------------------+

Re: [PATCH md 000 of 2] Introduction

[Neil Brown]

On Tuesday November 15, babydr@baby-dragons.com wrote:
>  	Hello Neil ,
> 
> On Tue, 15 Nov 2005, NeilBrown wrote:
> > +
> > +---------------------------
> > +
> > +What:  START_ARRAY ioctl for md
> > +When:  July 2006
> > +Files: drivers/md/md.c
> > +Why:   Not reliable by design - can fail when most needed.
> > +       Alternatives exist
> > +Who:   NeilBrown <neilb@suse.de>
> 
>  	Would some please update Documentation/md.txt with the alternates
>  	that exist to replace START_ARRAY ?  Or for that matter any kernel
>  	related document that covers the md driver &/or its tools .
>  		Tia ,  JimL
> 

Are you just asking "What are the 'Alternatives' that are claimed to
exist?"?
If so, then it is  'mdadm -A'.  I guess I could make that more
explicit.

Or are you asking something else?

NeilBrown

Re: [PATCH md 000 of 2] Introduction

[Mr. James W. Laferriere]

  	Hello Neil ,

On Thu, 17 Nov 2005, Neil Brown wrote:
> On Tuesday November 15, babydr@baby-dragons.com wrote:
>> On Tue, 15 Nov 2005, NeilBrown wrote:
>>> +
>>> +---------------------------
>>> +
>>> +What:  START_ARRAY ioctl for md
>>> +When:  July 2006
>>> +Files: drivers/md/md.c
>>> +Why:   Not reliable by design - can fail when most needed.
>>> +       Alternatives exist
>>> +Who:   NeilBrown <neilb@suse.de>
>>
>>  	Would some please update Documentation/md.txt with the alternates
>>  	that exist to replace START_ARRAY ?  Or for that matter any kernel
>>  	related document that covers the md driver &/or its tools .
>>  		Tia ,  JimL
> Are you just asking "What are the 'Alternatives' that are claimed to
> exist?"?
 	Yes ,  And to have them documented .

> If so, then it is  'mdadm -A'.  I guess I could make that more
> explicit.
 	Hmm ,  Where is mdadm documented as linux-raid tool(set) IN the
 	kernel tree ?  It's not in md.txt ..
# grep mdadm /usr/src/linux/Documentation/md.txt
#
 	Please help me(us) here .

> Or are you asking something else?
 	No ,  You got it right .  Tia ,  JimL
-- 
+------------------------------------------------------------------+
| James   W.   Laferriere | System    Techniques | Give me VMS     |
| Network        Engineer | 3542 Broken Yoke Dr. |  Give me Linux  |
| babydr@baby-dragons.com | Billings , MT. 59105 |   only  on  AXP |
+------------------------------------------------------------------+

Re: [PATCH md 002 of 2] Make md threads interruptible again.

[Neil Brown]

On Monday November 14, akpm@osdl.org wrote:
> NeilBrown <neilb@suse.de> wrote:
> >
> > 
> > Despite the fact that md threads don't need to be signalled, and won't
> > respond to signals anyway, we need to have an 'interruptible' wait,
> > else they stay in 'D' state and add to the load average.
> > 
> > ...
> > +		if (signal_pending(current))
> > +			flush_signals(current);
> 
> Kernel threads don't accept signals by default, so the above is
> unneeded.

Not by default, but md_thread calls
	allow_signal(SIGKILL);

because md_check_recovery (called by some, but not all, md_threads)
does
	if (signal_pending(current)) {
		if (mddev->pers->sync_request) {
			printk(KERN_INFO "md: %s in immediate safe mode\n",
			       mdname(mddev));
			mddev->safemode = 2;
		}
		flush_signals(current);
	}

i.e. We allow that if SIGKILL is sent to an md array controller thread
(as opposed to a resync thread), the array will be switched to
'immediate safe mode'.  In this mode the superblock is marked clean as
soon as there are no outstanding writes, rather than 20msecs later.
This if you 'alt-sysrq-K' then you can be fairly sure that the array
is marked clean NOW.

One of the reasons I did this was that I didn't like the whole idea of
md_notify_reboot which is hooked into the reboot notifiers chain and
switches all arrays to read-only, thus marking the superblock clean.
Having effectively the same thing happen on a SIGKILL to all processes
seemed a reasonable replacement.  However I haven't actually removed
md_notify_reboot yet....

NeilBrown

> 
> I'll leave it in there now, since that's how things used to be, but please
> make a note to nuke that check, then test it to make sure I'm telling the
> truth, then fix it up later on?

[PATCH md 000 of 2] Introduction

[NeilBrown]

Following are two patches for md in 2.6.15-rc what should get into
2.6.15-final if possible.

The first refines a newly created interface (/sys/block/mdX/md/level).
I've decided that 'raid5' is better than 'RAID-5' after all.

The second removes some limits that shouldn't really be imposed in the kernel.

Thanks,
NeilBrown



 [PATCH md 001 of 2] Change case of raid level reported in sys/mdX/md/level
 [PATCH md 002 of 2] Remove inappropriate limits in md/bitmap configuration.