This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 4/4] Remove broken posix_fallocate, posix_falllocate64 fallback code [BZ#15661]


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]