From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Staubach Subject: Re: [nfsv4] RE: Finding hardlinks Date: Thu, 04 Jan 2007 13:26:44 -0500 Message-ID: <459D46E4.1080102@redhat.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Trond Myklebust , Arjan van de Ven , Benny Halevy , Jan Harkes , Jeff Layton , linux-fsdevel@vger.kernel.org, Miklos Szeredi , Mikulas Patocka , nfsv4@ietf.org Return-path: Received: from mx1.redhat.com ([66.187.233.31]:53614 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S965066AbXADS1c (ORCPT ); Thu, 4 Jan 2007 13:27:32 -0500 To: Bryan Henderson In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Bryan Henderson wrote: >>>> "Clients MUST use filehandle comparisons only to improve >>>> performance, not for correct behavior. All clients need to >>>> be prepared for situations in which it cannot be determined >>>> whether two filehandles denote the same object and in such >>>> cases, avoid making invalid assumptions which might cause incorrect >>>> > behavior." > >>> Don't you consider data corruption due to cache inconsistency an >>> > incorrect behavior? > >> Exactly where do you see us violating the close-to-open cache >> consistency guarantees? >> > > Let me add the information that Trond is implying: His answer is yes, he > doesn't consider data corruption due to cache inconsistency to be > incorrect behavior. And the reason is that, contrary to what one would > expect, NFS allows that (for reasons of implementation practicality). It > says when you open a file via an NFS client and read it via that open > instance, you can legally see data as old as the moment you opened it. > Ergo, you can't use NFS in cases where that would cause unacceptable data > corruption. > > We normally think of this happening when a different client updates the > file, in which case there's no practical way for the reading client to > know his cache is stale. When the updater and reader use the same client, > we can do better, but if I'm not mistaken, the NFS protocol does not > require us to do so. And probably more relevant: the user wouldn't expect > cache consistency. This last is especially true, the expectations for use of NFS mounted file systems are pretty well known and have been set from years of experience. A workaround is provided for cooperating processes which need stronger consistency than the normal guarantees and that is file/record locking. Thanx... ps