From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: [RFC PATCH] fpathconf() for fsync() behavior Date: Thu, 23 Apr 2009 07:11:47 -0400 Message-ID: <20090423111147.GC4833@infradead.org> References: <20090423001257.GA16540@shell> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Chris Mason , Theodore Tso , Eric Sandeen , Ric Wheeler To: Valerie Aurora Henson Return-path: Received: from bombadil.infradead.org ([18.85.46.34]:58630 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754707AbZDWLLr (ORCPT ); Thu, 23 Apr 2009 07:11:47 -0400 Content-Disposition: inline In-Reply-To: <20090423001257.GA16540@shell> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Wed, Apr 22, 2009 at 08:12:57PM -0400, Valerie Aurora Henson wrote: > In the default mode for ext3 and btrfs, fsync() is both slow and > unnecessary for some important application use cases - at the same > time that it is absolutely required for correctness for other modes of > ext3, ext4, XFS, etc. If applications could easilyl distinguish > between the two cases, they would be more likely to be correct and > fast. > > How about an fpathconf() variable, something like _PC_ORDERED? E.g.: Before we add any new fpathconf varibale we need a reall (f)pathconf(at) syscall so that the fs driver can exposed it's characteristics, having to replicate that information to glibc especially for something required for data integrity is a receipe for a desaster.