Re: fallocate / posix_fallocate for new WAL file creation (etc...) - Mailing list pgsql-hackers

From Greg Smith
Subject Re: fallocate / posix_fallocate for new WAL file creation (etc...)
Date
Msg-id 51A73CA3.7000003@2ndQuadrant.com
Whole thread Raw
In response to Re: fallocate / posix_fallocate for new WAL file creation (etc...)  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: fallocate / posix_fallocate for new WAL file creation (etc...)  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
On 5/30/13 7:17 AM, Andres Freund wrote:
> That argument in contrast I find not very convincing though. What was
> the last incidence of such a system call that did not just error out
> with ENOTSUPP or such?

http://linux.die.net/man/2/posix_fadvise talks about  POSIX_FADV_NOREUSE 
and POSIX_FADV_WILLNEED being both buggy and quietly mapped to a no-op, 
depending on your version.  I know there were more examples than just 
that one that popped up during the testing of effective_io_concurrency.  My starting position has to assume that
posix_fallocatecan have the 
 
same sort of surprising behavior that showed up repeatedly when we were 
trying to use posix_fadvise more aggressively.

The way O_SYNC was quietly mapped to O_DSYNC (which isn't the same 
thing) was a similar issue, and that's the first one that left me 
forever skeptical of Linux kernel claims in this area until they are 
explicitly validated:  http://lwn.net/Articles/350225/

-- 
Greg Smith   2ndQuadrant US    greg@2ndQuadrant.com   Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: extensible external toast tuple support
Next
From: Andres Freund
Date:
Subject: Re: fallocate / posix_fallocate for new WAL file creation (etc...)