From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rob Ross Subject: Re: NFSv4/pNFS possible POSIX I/O API standards Date: Wed, 06 Dec 2006 10:42:45 -0600 Message-ID: <4576F305.6070504@mcs.anl.gov> References: <1164950795.5761.25.camel@lade.trondhjem.org> <1164984094.5761.86.camel@lade.trondhjem.org> <20061203015203.GA5656@schatzie.adilger.int> <20061204073200.GB5637@schatzie.adilger.int> <1165245336.711.176.camel@lade.trondhjem.org> <4574C48A.8030007@mcs.anl.gov> <1165298200.5776.26.camel@lade.trondhjem.org> <20061205100748.GC5871@infradead.org> <1165330516.5742.24.camel@lade.trondhjem.org> <4575EE84.6070604@mcs.anl.gov> <1165361095.5256.50.camel@lade.trondhjem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Christoph Hellwig , Andreas Dilger , Sage Weil , Brad Boyer , Anton Altaparmakov , Gary Grider , linux-fsdevel@vger.kernel.org Return-path: Received: from mailgw.mcs.anl.gov ([140.221.9.4]:38463 "EHLO mailgw.mcs.anl.gov" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S936399AbWLFQmt (ORCPT ); Wed, 6 Dec 2006 11:42:49 -0500 To: Trond Myklebust In-Reply-To: <1165361095.5256.50.camel@lade.trondhjem.org> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org Trond Myklebust wrote: > On Tue, 2006-12-05 at 16:11 -0600, Rob Ross wrote: >> Trond Myklebust wrote: >>> b) quite unnatural to impose caching semantics on all the >>> directory _entries_ using a syscall that refers to the directory >>> itself (see the explanations by both myself and Peter Staubach >>> of the synchronisation difficulties). Consider in particular >>> that it is quite possible for directory contents to change in >>> between readdirplus calls. >> I want to make sure that I understand this correctly. NFS semantics >> dictate that if someone stat()s a file that all changes from that client >> need to be propagated to the server? And this call complicates that >> semantic because now there's an operation on a different object (the >> directory) that would cause this flush on the files? > > The only way for an NFS client to obey the POSIX requirement that > write() immediately updates the mtime/ctime is to flush out all cached > writes whenever the user requests stat() information. Thanks for explaining this. I've never understood how it is decided where the line is drawn with respect to where NFS does obey POSIX semantics for a particular implementation. Writes on other nodes wouldn't necessarily have updated mtime/ctime, right? >>> i.e. the "strict posix caching model' is pretty much impossible >>> to implement on something like NFS or CIFS using these >>> semantics. Why then even bother to have "masks" to tell you when >>> it is OK to violate said strict model. >> We're trying to obtain improved performance for distributed file systems >> with stronger consistency guarantees than these two. > > So you're saying I should ignore this thread. Fine... No I'm trying to explain when the calls might be useful. But if you are only interested in NFS and CIFS, then I guess the thread might not be very interesting. >>> c) Says nothing about what should happen to non-stat() metadata >>> such as ACL information and other extended attributes (for >>> example future selinux context info). You would think that the >>> 'ls -l' application would care about this. >> Honestly, we hadn't thought about other non-stat() metadata because we >> didn't think it was part of the use case, and we were trying to stay >> close to the flavor of POSIX. If you have ideas here, we'd like to hear >> them. > > See my previous postings. I'll do that. Thanks. Rob