Subject: Re: NFS client behavior on close
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Simon Kirby <sim@netnation.com>
Cc: linux-kernel@vger.kernel.org
In-Reply-To: <20040602191603.GC4962@netnation.com>
References: <20040531213820.GA32572@netnation.com>
	 <1086159327.10317.2.camel@lade.trondhjem.org>
	 <20040602154146.GA2481@netnation.com>
	 <1086194307.17378.106.camel@lade.trondhjem.org>
	 <20040602191603.GC4962@netnation.com>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8BIT
Message-Id: <1086205521.4463.23.camel@lade.trondhjem.org>
Mime-Version: 1.0
Date: Wed, 02 Jun 2004 12:45:21 -0700
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1331
Lines: 31

P? on , 02/06/2004 klokka 12:16, skreiv Simon Kirby:

> Ok, that makes sense -- if NFSv2 has no fsync(), then using "async" mode
> definitely sounds broken.  But is this the same with NFSv3?

The problem is that Linux's "async" implementation short-circuits the
NFSv3 fsync() equivalent. Not good!


> NFS should just extend fsync() back to the server -- with minimal caching
> on the client, normal write-back caching on the server, and where fsync()
> on the client forces the server to write before returning on the client. 
> Forcing this to happen on close() doesn't even line up with local file
> systems.

That still leaves room for races with other clients trying to open the
file after the server comes up after a crash, then finding stale data.
(Free|Net|Open)BSD choose to ignore that race, and do the above. I'm not
aware of anybody else doing so, though...

Performance is good, but it should always take second place to data
integrity. There are more than enough people out there who are
entrusting research projects, banking data,... to their NFS server.

Cheers,
  Trond
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/