All of lore.kernel.org
 help / color / mirror / Atom feed
From: "J. Bruce Fields" <bfields@fieldses.org>
To: Neil Brown <neilb@suse.de>
Cc: nfs@lists.sourceforge.net
Subject: [PATCH] Use __fpurge to ensure single-line writes to cache files
Date: Thu, 26 Jul 2007 16:30:46 -0400	[thread overview]
Message-ID: <20070726203046.GG8125@fieldses.org> (raw)
In-Reply-To: <18088.7847.592861.408080@notabene.brown>

From: J. Bruce Fields <bfields@citi.umich.edu>

On a recent Debian/Sid machine, I saw libc retrying stdio writes that
returned write errors.  The result is that if an export downcall returns
an error (which it can in normal operation, since it currently
(incorrectly) returns -ENOENT on any negative downcall), then subsequent
downcalls will write multiple lines (including the original line that
received the error).

The result is that the server fails to respond to any rpc call that
refers to an unexported mount point (such as a readdir of a directory
containing such a mountpoint), so client commands hang.

I don't know whether this libc behavior is correct or expected, but it
seems safest to add the __fpurge() (suggested by Neil) to ensure data is
thrown away.

Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
---
 support/nfs/cacheio.c |   12 ++++++++++++
 1 files changed, 12 insertions(+), 0 deletions(-)

On Thu, Jul 26, 2007 at 02:10:15PM +1000, Neil Brown wrote:
> 	__fpurge(f)
> 
> seems to do the trick.

Yep, thanks!

> But we want to build a line up from multiple words, and so we need
> buffering for that.  If we toss stdio, we will need to allocate a
> buffer, keep track of the end point, and append to the buffer in
> various places.  It feels like reinventing the wheel.

Reinventing a rather simple part of the wheel, I'd say.  Oh well,
another day.

--b.


diff --git a/support/nfs/cacheio.c b/support/nfs/cacheio.c
index a76915b..9d271cd 100644
--- a/support/nfs/cacheio.c
+++ b/support/nfs/cacheio.c
@@ -17,6 +17,7 @@
 
 #include <nfslib.h>
 #include <stdio.h>
+#include <stdio_ext.h>
 #include <ctype.h>
 #include <unistd.h>
 #include <sys/types.h>
@@ -111,7 +112,18 @@ void qword_printint(FILE *f, int num)
 
 int qword_eol(FILE *f)
 {
+	int err;
+
 	fprintf(f,"\n");
+	err = fflush(f);
+	/*
+	 * We must send one line (and one line only) in a single write
+	 * call.  In case of a write error, libc may accumulate the
+	 * unwritten data and try to write it again later, resulting in a
+	 * multi-line write.  So we must explicitly ask it to throw away
+	 * any such cached data:
+	 */
+	__fpurge(f);
 	return fflush(f);
 }
 
-- 
1.5.3.rc2


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
NFS maillist  -  NFS@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nfs

  reply	other threads:[~2007-07-26 20:30 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-25 22:37 stdio and nfs-utils J. Bruce Fields
2007-07-26  0:07 ` J. Bruce Fields
2007-07-26  2:59   ` Neil Brown
2007-07-26  3:17     ` J. Bruce Fields
2007-07-26  4:10       ` Neil Brown
2007-07-26 20:30         ` J. Bruce Fields [this message]
2007-07-26 20:31         ` [PATCH] knfsd: eliminate unnecessary -ENOENT returns on export downcalls J. Bruce Fields
2007-07-26 18:43       ` Exportfs not showing exported file systems (was RE: stdio and nfs-utils) Muntz, Daniel
2007-07-26 19:36         ` J. Bruce Fields
2007-07-26 19:48         ` Jeff Layton
2007-07-26 20:04           ` J. Bruce Fields
2007-07-26 20:42           ` Muntz, Daniel
2007-07-26 21:12             ` Jeff Layton
2007-07-26 21:16               ` J. Bruce Fields
2007-07-26 21:40               ` Muntz, Daniel
2007-07-27 14:40                 ` Steve Dickson

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=20070726203046.GG8125@fieldses.org \
    --to=bfields@fieldses.org \
    --cc=neilb@suse.de \
    --cc=nfs@lists.sourceforge.net \
    /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.