From: Wendy Cheng <s.wendy.cheng@gmail.com>
To: Bernd Schubert <bs-PKu+Ek1N2UGzQB+pC5nmwQ@public.gmane.org>
Cc: linux-nfs@vger.kernel.org
Subject: Re: multiple instances of rpc.statd
Date: Fri, 25 Apr 2008 09:47:03 -0400 [thread overview]
Message-ID: <4811E0D7.4070608@gmail.com> (raw)
In-Reply-To: <200804251531.21035.bs-PKu+Ek1N2UGzQB+pC5nmwQ@public.gmane.org>
Bernd Schubert wrote:
> Hello,
>
> on servers with heartbeat managed resources one rather often has the situation
> one exports different directories from different resources.
>
> It now may happen all resources are running on one host, but they can also run
> from different hosts. The situation gets even more complicated if the server
> is also a nfs client.
>
> In principle having different nfs resources works fine, only the statd state
> directory is a problem. Or in principle the statd concept at all. Actually we
> would need to have several instances of statd running using different
> directories. These then would have to be migrated from one server to the
> other on resource movement.
> However, as far I understand it, there does not even exist the basic concept
> for this, doesn't it?
>
>
The efforts have been attempted (to remedy this issue) and a complete
set of patches have been (kept) submitting for the past two years. The
patch acceptance progress is very slow (I guess people just don't want
to get bothered with cluster issues ?).
Anyway, the kernel side has the basic infrastructure to handle the
problem (it stores the incoming clients IP address as part of its
book-keeping record) - just a little bit tweak will do the job. However,
the user side statd directory needs to get re-structured. I didn't
publish the user side directory structure script during my last round of
submission. Forking statd into multiple threads do not solve all the
issues. Check out:
https://www.redhat.com/archives/cluster-devel/2007-April/msg00028.html
-- Wendy
next prev parent reply other threads:[~2008-04-25 13:45 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-04-25 13:31 multiple instances of rpc.statd Bernd Schubert
[not found] ` <200804251531.21035.bs-PKu+Ek1N2UGzQB+pC5nmwQ@public.gmane.org>
2008-04-25 13:47 ` Wendy Cheng [this message]
2008-04-25 14:30 ` Bernd Schubert
[not found] ` <200804251630.36917.bs-PKu+Ek1N2UGzQB+pC5nmwQ@public.gmane.org>
2008-04-25 15:39 ` Wendy Cheng
2008-04-25 22:07 ` J. Bruce Fields
2008-04-28 3:59 ` Wendy Cheng
2008-04-28 18:26 ` J. Bruce Fields
2008-04-28 19:19 ` Wendy Cheng
2008-04-29 16:20 ` J. Bruce Fields
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4811E0D7.4070608@gmail.com \
--to=s.wendy.cheng@gmail.com \
--cc=bs-PKu+Ek1N2UGzQB+pC5nmwQ@public.gmane.org \
--cc=linux-nfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.