Peter Eriksson wrote:
> I've (slowly) been trying to figure out why there seems to be a problem with
> "fsync()"... Example code:
>
> #include <errno.h>
> int main(int argc, char **argv)
> {
> int rc = 0, fd, res;
>
> fd = creat("dummy.txt", 0666);
> res = write(fd, "test", 4);
>
> if (argc > 1)
> rc = fsync(fd);
>
> printf("fd = %d, res = %d, rc = %d, errno = %d\n", fd, res, rc, errno);
> }
>
> Running this code on a SGI client running IRIX 6.5.28f in a SecureNFS-mounted
> directory fails if fsync() is called. I *suspect* that this is due to a
> problem on the SGI side (but talking to SGI Support is, well, about as
> effective as talking to a brick wall) so I'd like to really make sure it
> isn't a Solaris bug (which I doubt). Has anyone else seen this error?
>
> (I have a case open with Sun Support regarding this but I figured I'd check
> here too)
Hi Peter,
It would be helpful if you could include the errno that fsync() returns. Do
you know if the create and the write succeeded? The code above only pays
attention to fsync's return value.
To investigate further, please log onto the Solaris server and grab a snoop
trace. Of course snoop traces aren't very useful for mounts using krb5p
(privacy/encryption), so please mount using krb5i (integrity) or krb5
(authentication only).
You didn't mention this, but does the program work okay using insecure
mounts (in other words, it only fails for krb mounts)?
Here's the snoop command to run on the server:
snoop -d <interface> -o /tmp/fsync.cap <client-hostname>
<interface> would be something like: bge0. eri0, etc.
After the client prog fails, run snoop -i /tmp/fsync.cap | grep NFS
to see the NFS traffic. Of course, you'll want to minimize NFS traffic
not related to your prog between the 2 machines; otherwise, finding
the NFS-related traffic generated from your test case could be a
little painful.
Jeff
