This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 4/4] Remove broken posix_fallocate, posix_falllocate64 fallback code [BZ#15661]
- From: Rich Felker <dalias at libc dot org>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: Christoph Hellwig <hch at lst dot de>, Florian Weimer <fweimer at redhat dot com>, libc-alpha at sourceware dot org
- Date: Wed, 6 May 2015 19:29:34 -0400
- Subject: Re: [PATCH 4/4] Remove broken posix_fallocate, posix_falllocate64 fallback code [BZ#15661]
- Authentication-results: sourceware.org; auth=none
- References: <20150424134516 dot 6795441F484D0 at oldenburg dot str dot redhat dot com> <554927F9 dot 7080509 at redhat dot com> <20150505204808 dot GA12948 at lst dot de> <554A8090 dot 2090903 at redhat dot com>
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