Introduction
Subsystems (2)
PATCH 1/1 Introduction
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 1/1 Mark START_ARRAY deprecated with a date.
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.
### Diffstat output
./Documentation/feature-removal-schedule.txt | 9 +++++++++ ./drivers/md/md.c | 2 +- 2 files changed, 10 insertions(+), 1 deletion(-)
Documentation/feature-removal-schedule.txt renamed from Documentation/feature-removal-schedule.txt~current~ +9 -0
@@ -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 <[email protected]> + +--------------------------- + +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 <[email protected]>
drivers/md/md.c renamed from drivers/md/md.c~current~ +1 -1
@@ -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 1/1 Make md threads interruptible again.
In reply to NeilBrownDespite 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.
### Diffstat output
./drivers/md/md.c | 17 +++++++++++++---- 1 file changed, 13 insertions(+), 4 deletions(-)
drivers/md/md.c renamed from drivers/md/md.c~current~ +13 -4
@@ -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.
drivers/md/md.c static int md_thread(void * arg) · line 3446
Quoted 9 lines · 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.
...
drivers/md/md.c renamed from drivers/md/md.c~current~ +2
-0+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.
Quoted 7 lines · On Monday November 14, [email protected] wrote:
Quoted 6 lines · 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.
Quoted 6 lines
drivers/md/md.c static int md_thread(void * arg) · line 3446
Quoted 3 lines
...
drivers/md/md.c renamed from drivers/md/md.c~current~ +2
-0+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
Quoted 4 lines
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?
Hello Neil ,
Quoted 18 lines · 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_ARRAYioctl.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_ARRAYdeprecated with a date. [PATCH md 002 of 2] Make md threads interruptible again.diff
./Documentation/feature-removal-schedule.txt~current~/Documentation/feature-removal-schedule.txtDocumentation/feature-removal-schedule.txt 2005-11-15 10:25:30.000000000 +1100 renamed from Documentation/feature-removal-schedule.txt~current~ 2005-11-15 10:25:30.000000000 +1100 +0
-0@@ -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.
Documentation/feature-removal-schedule.txt 2005-11-15 10:25:30.000000000 +1100 What: EXPORT_SYMBOL(lookup_hash) · line 142
Quoted 10 lines
Documentation/feature-removal-schedule.txt 2005-11-15 10:25:30.000000000 +1100 renamed from Documentation/feature-removal-schedule.txt~current~ 2005-11-15 10:25:30.000000000 +1100 +9
-0Who: Christoph Hellwig <[email protected]> + +--------------------------- + +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 <[email protected]>
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
Signature · 5 lines
+------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network Engineer | 3542 Broken Yoke Dr. | Give me Linux | | [email protected] | Billings , MT. 59105 | only on AXP | +------------------------------------------------------------------+
Quoted 14 lines · On Tuesday November 15, [email protected] wrote:
Hello Neil ,
Quoted 9 lines · NeilBrown
(quoted diff) +9
-0+ +--------------------------- + +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 <[email protected]>
Review
Quoted 4 lines
(quoted diff) +0
-0Would 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
Hello Neil ,
Quoted 16 lines · Neil Brown
Quoted 11 lines · On Tuesday November 15, [email protected] wrote:
Quoted 9 lines · NeilBrown
(quoted diff) +9
-0+ +--------------------------- + +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 <[email protected]>Review
Quoted 4 lines
(quoted diff) +0
-0Would 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
Quoted 2 lines
Are you just asking "What are the 'Alternatives' that are claimed to exist?"?
Yes , And to have them documented .
Quoted 2 lines
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 .
Quoted 1 line
Or are you asking something else?
No , You got it right . Tia , JimL
Signature · 5 lines
+------------------------------------------------------------------+ | James W. Laferriere | System Techniques | Give me VMS | | Network Engineer | 3542 Broken Yoke Dr. | Give me Linux | | [email protected] | Billings , MT. 59105 | only on AXP | +------------------------------------------------------------------+