From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christoph Hellwig Subject: Re: adding proper O_SYNC/O_DSYNC, was Re: O_DIRECT and barriers Date: Fri, 28 Aug 2009 18:39:54 -0400 Message-ID: <20090828223953.GA11591@infradead.org> References: <20090828154647.GA15808@infradead.org> <4A98008B.6050503@redhat.com> <20090828161745.GA8755@infradead.org> <4A9806D9.5050409@redhat.com> <20090828164106.GA9951@infradead.org> <4A984337.7080009@redhat.com> <20090828210838.GA26799@infradead.org> <1251494174.5984.2.camel@heimdal.trondhjem.org> <20090828212921.GA13662@infradead.org> <1251495785.5984.13.camel@heimdal.trondhjem.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Christoph Hellwig , Ulrich Drepper , Jamie Lokier , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, torvalds@linux-foundation.org To: Trond Myklebust Return-path: Content-Disposition: inline In-Reply-To: <1251495785.5984.13.camel@heimdal.trondhjem.org> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Fri, Aug 28, 2009 at 05:43:05PM -0400, Trond Myklebust wrote: > If you are going to automatically set O_DSYNC in open(), then > fcntl(F_SETFL) might get a bit nasty. > > Imagine using it after the open in order to clear the O_ISYNC flag; > you'll still be left with the O_DSYNC (which you never set in the first > place). That would be confusing... Indeed, that's a killer argument for the first variant. We just need to make it extremly clear (manpage _and_ comments) that only O_SYNC is an exposed user interface and that O_WHATEVER_SYNC is an implementation detail.