On Monday November 14, akpm@xxxxxxxx wrote:
> NeilBrown <neilb@xxxxxxx> 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?
-
To unsubscribe from this list: send the line "unsubscribe linux-raid" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
