summaryrefslogtreecommitdiffstats
path: root/utils/statd/sm-notify.c
diff options
context:
space:
mode:
authorJ. Bruce Fields <bfields@citi.umich.edu>2007-07-26 16:30:46 -0400
committerNeil Brown <neilb@suse.de>2007-07-27 10:25:52 +1000
commitdd087896285da9e160e13ee9f7d75381b67895e3 (patch)
tree23d1a23f6e7c21c64ca4ec7aff0b7913fdfd4ddc /utils/statd/sm-notify.c
parent525b122699b1b899815a76630ae2ee2feb551fe4 (diff)
downloadnfs-utils-dd087896285da9e160e13ee9f7d75381b67895e3.tar.gz
nfs-utils-dd087896285da9e160e13ee9f7d75381b67895e3.tar.xz
nfs-utils-dd087896285da9e160e13ee9f7d75381b67895e3.zip
Use __fpurge to ensure single-line writes to cache files
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> Signed-off-by: Neil Brown <neilb@suse.de>
Diffstat (limited to 'utils/statd/sm-notify.c')
0 files changed, 0 insertions, 0 deletions