Q: Priority of md_thread()

Q: Priority of md_thread()

[Potthoff, Kay]

I have a question regarding the priority of the md_thread() function
(defined in md.c).

I have seen that the priority of this thread is set to -20 (parameter
current->nice), which means that this thread takes the highest priority. The
problem I have is that this thread blocks some other task that is answering
keep alive network pings from another (sibling) node. Because the keep alive
answers are blocked the other node decides to take-over the RAID. This
situation leeds to the fact that two nodes try to start the RAID. MD don't
like this. The RAID is considered to be faulty and both nodes try to repair
it, that is a problem.

I figuered out that the cause of this problem is the high priority of the
md_thread() function. I feel tempted to decrease this priority, but I feel
some upcoming ache in my belly because I don't know the exact reason why the
priority had been set to -20. I hope that somebody can explain me why! The
comments in the sources seem to regard to RAID-5 personality. If so that
would be no problem, I intend only to use RAID-1.

Thanks in advance, Kay

######################################################
# Kay Potthoff              Senior Software Engineer
#
# FORCE Computers GmbH        Tel.: +49-89-60814-356
# Prof.-Messerschmitt-Str. 1    FAX : +49-89-6097793
# 85579 Neubiberg/München
# Deutschland/Germany
#
# mailto:Kay.Potthoff@force.de
######################################################
-
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: Q: Priority of md_thread()

[Jakob Østergaard]

On Wed, May 22, 2002 at 01:59:57PM +0200, Potthoff, Kay wrote:
> I have a question regarding the priority of the md_thread() function
> (defined in md.c).
> 
> I have seen that the priority of this thread is set to -20 (parameter
> current->nice), which means that this thread takes the highest priority. The
> problem I have is that this thread blocks some other task that is answering
> keep alive network pings from another (sibling) node. Because the keep alive
> answers are blocked the other node decides to take-over the RAID. This
> situation leeds to the fact that two nodes try to start the RAID. MD don't
> like this. The RAID is considered to be faulty and both nodes try to repair
> it, that is a problem.

That system cannot be stable.

Remember the -20 is only for the CPU scheduler, and the md_thread is not CPU
bound (unless you have ISA controllers, or *very* special disks).  What I am
trying to say is, I doubt much would change if the nice level was changed to
20 instead...

I think your problem is that something (and probably as you state, md_thread)
is causing fluctuations in the ping replies, causing your other nodes to take
an action which they shouldn't take based on a ping fluctuation (that could
just as easily be caused by a packet loss or some other random event in the
whole computer-network-computer system).

If you want multiple nodes mounting the same array, you need some consistency
protocol to be able to *guarantee* that no two nodes will try to master the
same array simultaneously. Ping fluctuations do not constitute a consistency
protocol.


> I figuered out that the cause of this problem is the high priority of the
> md_thread() function. I feel tempted to decrease this priority, but I feel
> some upcoming ache in my belly because I don't know the exact reason why the
> priority had been set to -20. I hope that somebody can explain me why! The
> comments in the sources seem to regard to RAID-5 personality. If so that
> would be no problem, I intend only to use RAID-1.

Please let me know if I completely misunderstood the situation   :)

-- 
................................................................
:   jakob@unthought.net   : And I see the elder races,         :
:.........................: putrid forms of man                :
:   Jakob Østergaard      : See him rise and claim the earth,  :
:        OZ9ABN           : his downfall is at hand.           :
:.........................:............{Konkhra}...............:
-
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: Q: Priority of md_thread()

[Potthoff, Kay]

First of all, thanks for your reply! I feel relieved!

> 
> Remember the -20 is only for the CPU scheduler, and the 
> md_thread is not CPU
> bound (unless you have ISA controllers, or *very* special 
> disks).  What I am
> trying to say is, I doubt much would change if the nice level 
> was changed to
> 20 instead...

Me too, I'm not sure what influences such a change would have. If I
understood you correct, does that mean that setting the nice level to -20 is
necessary to avoid trouble on multi-processor platforms? If so, can the
problem be solved binding md_thread to one CPU during its livetime? I don't
know if Linux is offering such a feature, but as I remember once Solaris
supported that.

> 
> I think your problem is that something (and probably as you 
> state, md_thread)
> is causing fluctuations in the ping replies, causing your 
> other nodes to take
> an action which they shouldn't take based on a ping 
> fluctuation (that could
> just as easily be caused by a packet loss or some other 
> random event in the
> whole computer-network-computer system).
> 

That is right. I have an High-Availability framework that realizes an
active-standby model on two nodes. That means only one owns the RAID at a
time the other node is standby and does not access the disks while it is
standby. Only in case of a node failure of the active node the HA-framework
decides to move the ownership of the RAID to the standby node. This
detection mechanism is realized using keep alive pings through two seperate
heartbeat ethernet connections exclusively between the nodes.

> 
> Please let me know if I completely misunderstood the situation   :)

Don't be anxious, you didn't ;-)

Regards, Kay