From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-alpha-return-58736-listarch-libc-alpha=sources.redhat.com@sourceware.org>
Received: (qmail 88210 invoked by alias); 6 May 2015 23:29:43 -0000
Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <libc-alpha.sourceware.org>
List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: libc-alpha-owner@sourceware.org
Received: (qmail 88197 invoked by uid 89); 6 May 2015 23:29:42 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-0.3 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RDNS_DYNAMIC,TVD_RCVD_IP autolearn=no version=3.3.2
X-HELO: brightrain.aerifal.cx
Date: Wed, 06 May 2015 23:29:00 -0000
From: Rich Felker <dalias@libc.org>
To: Carlos O'Donell <carlos@redhat.com>
Cc: Christoph Hellwig <hch@lst.de>, Florian Weimer <fweimer@redhat.com>,
	libc-alpha@sourceware.org
Subject: Re: [PATCH 4/4] Remove broken posix_fallocate, posix_falllocate64
 fallback code [BZ#15661]
Message-ID: <20150506232934.GP17573@brightrain.aerifal.cx>
References: <20150424134516.6795441F484D0@oldenburg.str.redhat.com>
 <554927F9.7080509@redhat.com>
 <20150505204808.GA12948@lst.de>
 <554A8090.2090903@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <554A8090.2090903@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-SW-Source: 2015-05/txt/msg00092.txt.bz2

On Wed, May 06, 2015 at 04:58:56PM -0400, Carlos O'Donell wrote:
> On 05/05/2015 04:48 PM, Christoph Hellwig wrote:
> > On Tue, May 05, 2015 at 04:28:41PM -0400, Carlos O'Donell wrote:
> >> The other side of the coin is that POSIX goes on further to say in
> >> "2.9.7 Thread Interactions with Regular File Operations" that threads
> >> should never see interleaving sets of file operations, but it is insane
> >> to do anything like that because it kills performance, so you don't get
> >> those guarantees in Linux.
> > 
> > Which specific guarantees do you see violated with a sane filesystem like
> > XFS?
> 
> I have not verified that XFS behaves as is expected by POSIX, but I was 
> going by Linus's comments when this issue was discussed and then fixed
> in 3.14.
> 
> In particular:
> http://article.gmane.org/gmane.linux.kernel/398249
> 
> With the original thread here:
> http://thread.gmane.org/gmane.linux.kernel/397980
> 
> Would an fstat on XFS show the in-progress IO being done by a call to
> write? If it does, then it violates POSIX, which requires that none
> or all of the write show up in the fstat call.
> 
> The standard statement in question is:
> ~~~
> 2.9.7 Thread Interactions with Regular File Operations
> All of the functions chmod( ), close( ), fchmod( ), fcntl( ), fstat( ), 
> ftruncate( ), lseek( ), open( ), read( ), readlink( ), stat( ), symlink( ), 
> and write( ) shall be atomic with respect to each other in the effects 
> specified in IEEE Std 1003.1-2001 when they operate on regular files. If two 
> threads each call one of these functions, each call shall either see all of 
> the specified effects of the other call, or none of them.
> ~~~

I'm pretty sure Linux has a lot of bugs in this regard. Unless the
standard is to be relaxed, I think the right solution is either for
the kernel to simulate atomicity or to break out of the long write and
return a short write when another operation tries to access the file
state while it's in progress. Sadly there does not seem to be anything
userspace can do to work around the kernel bugs, though.

Rich