From: Eric Werme USG (werme@zk3.dec.com)
Date: 09/14/99-01:34:26 PM Z
From: Eric Werme USG <werme@zk3.dec.com>
Message-Id: <199909141834.OAA0000729854@anw.zk3.dec.com>
Subject: Re: fsync() fails under NFS, right?
Date: Tue, 14 Sep 1999 14:34:26 -0400
Alexy Khrabrov wrote:
> I was away from my mail, but want to thank all who
> responded. For us, the issue is very crucial, and
> it is interesting that it doesn't look as such to
> many NFS folks.
It does, however, there's a saying that "extraordinary claims
need extraordinary proof". While we all can readily conceive
of fsync failures (it wouldn't even be extraordinary), you have
presented no proof at all. We're still waiting.
Dave Noveck replied:
No theoretical problems. The server doesn't see
fsync as an operation. It sees the WRITE requests
that the server should generate (and possibly a COMMIT).
A server would have to try very hard to make fsync not
work. If it is not doing WRITE and COMMIT's properly,
lots of stuff wouldn't work. It is easier for a
client to have an fsync bug but if you think you
have one, you need to demonstrate it with a
small test program and a packet trace showing that
the correct WRITE requests are not in fact being
issued.
The other reason it may appear that we are disinterested is because
this is a mail list for the discussion of future directions for NFS
protocol development. No one has brought up any protocol changes necessary
to support fsync() because we all think the V2, V3, and V4 protocols
adequately allow fsync() to be implemented using the protocol. You're
talking to the wrong audience!
I can't speak for my collegues, but I spend more time than I need
(or should?) answering NFS questions on comp.protocols.nfs and
comp.sys.dec. That can often save a lot of time instead of going
through support depeartments, especially if two vendors are involved.
On the other hand, we were hired for developing new, working NFS
code. The support engineers were hired to handle most any problem
a customer encounters and generally have a broader knowledge of
pitfalls. They can also help you collect traces for study. We
can't give you that much time.
To the best of my knowledge, Tru64 NFS properly implements fsync(2).
I've read the code, I've studied tcpdump traces, I've timed transfers,
I've counted disk reads and writes. My rivals and collegues have
done the same. I've forgotten what vendors you're using. I admit
I'd be delighted to know if Sun or HP or NetApp had a broken fsync(2).
But I'd be pretty surprised.
-Ric Werme
This archive was generated by hypermail 2.1.2 : 03/04/05-01:47:34 AM Z CST