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 17:29:21 -0400 Message-ID: <20090828212921.GA13662@infradead.org> References: <20090827171044.GA5427@infradead.org> <4A96C14C.8040105@redhat.com> <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> 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: Received: from bombadil.infradead.org ([18.85.46.34]:48465 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751581AbZH1V3a (ORCPT ); Fri, 28 Aug 2009 17:29:30 -0400 Content-Disposition: inline In-Reply-To: <1251494174.5984.2.camel@heimdal.trondhjem.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Fri, Aug 28, 2009 at 05:16:14PM -0400, Trond Myklebust wrote: > On Fri, 2009-08-28 at 17:08 -0400, Christoph Hellwig wrote: > > #define O_SYNC (O_FULLSYNC|O_DSYNC) > > > > - during the normal merge window I will add a real implementation for > > for O_FULLSYNC and O_RSYNC > > > > P.S. better naming suggestions for O_FULLSYNC welcome > > Basically you are just ensuring that the metadata changes are being > synced together with the data changes, so how about O_ISYNC (inode > sync)? Yeah. Thinking about this a bit more we should define this flag much more clearly. In the obvious implementation it would not actually do anything if it's set on it's own. We would only check it if O_DSYNC is already set to decided if we want to set the datasync argument to ->fsync to 0 or 1 for the generic filesystems (and similar things for filesystems not using the generic helper). If we deem that this is too unsafe we could make sure O_DSYNC always gets set on this fag in ->open, but if we make sure O_SYNC is defined like the one above in the kernel headers and glibc we should be fine. Although in that case a name that doesn't suggest that it actually does something useful would be better.