public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "schönfeld / in-medias-res" <schoenfeld@in-medias-res.com>
To: linux-kernel@vger.kernel.org
Subject: Re: ncpfs: Connection invalid / Input-/Output Errors
Date: Fri, 09 Sep 2005 13:16:31 +0200	[thread overview]
Message-ID: <43216F0F.3040104@in-medias-res.com> (raw)
In-Reply-To: <432167F1.8020902@vc.cvut.cz>

Petr Vandrovec schrieb:
> schönfeld / in-medias-res wrote:
> 
>> Hi Petr,
>>
>> the two servers is that the one with the problems does run a nagios nrpe
>> server and some plugins, e.g. to check disk space on the novell disk,
>> while the other server does not. Now i found that heavy operations on
>> the filesystem (e.g. stat'ing many small files in a short time) is a
>> kind of problematic, if you want to do anything else on the filesystem
>> at the same time. The second process just hangs until the first one
>> accessing the ncp filesystem is ready with its operation. Well if
> 
> 
> You need either another CPU, or semaphore which do not suffer from
> starvation.
> Or you have to rewrite ncpfs to use some queue instead of simple
> semaphore.  What happens is that your copy process in a loop acquires
> ncp_server's semaphore, sends request to server, waits for response, and
> releases semaphore.  It does that for every request sent out.  Now your
> process comes in, finds that ncp_server's semaphore is locked, and starts
> waiting.  Other process gets answer from server, releases semaphore, and
> as both processes were just waiting before this happened, they both have
> same priority, and so one which just did up() continues to run.  And
> before waken up process gets chance to do its task, copy process sends
> another request, and so your second process goes to sleep again.

Ah thanks. That makes things a lot of clearer.

I found out that my attemption were true: the plugin really gets a KILL
signal if it exceeds the timeout. Means that the nagios check plugin is
the source of the problem (in combination with that what you did explain
AND the process which uses the ncpfs regulary and is running constant).
Now we found a solution for that. We just start the always
running process with a lower priority. That makes ncpfs access possible
while this process is running and producing load. Now: If we have the
always running process running, with low priority (nice +5), and the
nagios plugin tries to do something on the ncpfs it is able to, runs
fine and exits gracefully. Problem solved, at least until we find a
solution that does not look like a workaround ;-)

Thanks for your help! You helped me very much.

Bye
Patrick

      reply	other threads:[~2005-09-09 11:14 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <S932080AbVIGI45/20050907085657Z+286@vger.kernel.org>
2005-09-07 11:08 ` ncpfs: Connection invalid / Input-/Output Errors schönfeld / in-medias-res
2005-09-07 12:11   ` Anton Altaparmakov
2005-09-07 14:14     ` schönfeld / in-medias-res
2005-09-07 16:24       ` Petr Vandrovec
2005-09-09  7:36         ` schönfeld / in-medias-res
2005-09-09 10:46           ` Petr Vandrovec
2005-09-09 11:16             ` schönfeld / in-medias-res [this message]

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=43216F0F.3040104@in-medias-res.com \
    --to=schoenfeld@in-medias-res.com \
    --cc=linux-kernel@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox