From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Dilger Subject: Re: fgetattr/fsetattr file operation Date: Thu, 04 Jun 2009 13:04:24 -0600 Message-ID: <20090604190424.GI9002@webber.adilger.int> References: Mime-Version: 1.0 Content-Type: text/plain; CHARSET=US-ASCII Content-Transfer-Encoding: 7BIT Cc: Miklos Szeredi , linux-fsdevel@vger.kernel.org To: Brian Molnar Return-path: Received: from sca-es-mail-2.Sun.COM ([192.18.43.133]:50146 "EHLO sca-es-mail-2.sun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751630AbZFDTEl (ORCPT ); Thu, 4 Jun 2009 15:04:41 -0400 Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n54J4aNl022107 for ; Thu, 4 Jun 2009 12:04:39 -0700 (PDT) Content-disposition: inline Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KKQ00400A2TY100@fe-sfbay-09.sun.com> for linux-fsdevel@vger.kernel.org; Thu, 04 Jun 2009 12:04:36 -0700 (PDT) In-reply-to: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Jun 04, 2009 10:42 -0700, Brian Molnar wrote: > > On Thu, Jun 4, 2009 at 3:27 AM, Miklos Szeredi wrote: > > Can you tell us a bit more about your use case, and how you worked > > around the limitation? > > In this FS, when a process opens a file for write mode access, it > maintains its own private copy of the file until it comes time to > close. Upon close, this private copy is "committed" and replaces the > file on-disk. Meanwhile, while the file is open for writing (before > close) the file on-disk remains untouched (both data and metadata). > Thus, any metadata-changing operations that take place against the > file descriptor must only be seen to the process(es) using that file > descriptor. The intended behavior is that an fstat(2) against the file > descriptor will return the attributes corresponding to the > uncommitted, private copy and a path-based stat(2) will return the > attributes of the file on-disk. This sounds very strange - different processes (or even the same process using different file handles) will see different results for fstat() which are yet different from stat(). I can't imagine that applications would like this at all. > To achieve this behavior, Maybe you should go back and explain why this behaviour is useful, before we burden the kernel with it. Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc.