[PATCH md 000 of 2] Introduction

[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 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?

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 |
+------------------------------------------------------------------+