Subject: Re: [BUG] NFS no longer updates file modification times
	appropriately
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: joe.korty@ccur.com
Cc: linux-kernel@vger.kernel.org, Ronny.Lampert@telecasystems.de,
       ioe-lkml@rameria.de
In-Reply-To: <1086627207.4597.4.camel@lade.trondhjem.org>
References: <1086625209.4597.0.camel@lade.trondhjem.org>
	 <20040607163920.GB22505@tsunami.ccur.com>
	 <1086627207.4597.4.camel@lade.trondhjem.org>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8BIT
Message-Id: <1086627686.4597.10.camel@lade.trondhjem.org>
Mime-Version: 1.0
Date: Mon, 07 Jun 2004 13:01:26 -0400
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1025
Lines: 26

P? m? , 07/06/2004 klokka 12:53, skreiv Trond Myklebust:
> > 
> > Compatibility with existing behavior.  It's called a de-facto standard.
> 
> The "de-facto standard" you describe has never existed other than for
> large files. It was never true of small files that did not trigger
> immediate writeout.

...in fact even for files that trigger immediate writeout, the behaviour
was erratic, since writes could still be cached after the
memory-triggered flush was completed.

So I repeat: There has *never* been a standard other than the
close-to-open.

There has *never* existed any reliable mtime/ctime while the client was
caching writes.

If you want that sort of behaviour, the options are O_SYNC, fsync(),
close(), or "mount -osync". There is no call for it in async writes.

-
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/