| From: | Greg Smith <greg(at)2ndQuadrant(dot)com> |
|---|---|
| To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Jon Nelson <jnelson+pgsql(at)jamponi(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: fallocate / posix_fallocate for new WAL file creation (etc...) |
| Date: | 2013-05-30 11:48:51 |
| Message-ID: | 51A73CA3.7000003@2ndQuadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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_fallocate can 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(at)2ndQuadrant(dot)com Baltimore, MD
PostgreSQL Training, Services, and 24x7 Support www.2ndQuadrant.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2013-05-30 11:52:35 | Re: fallocate / posix_fallocate for new WAL file creation (etc...) |
| Previous Message | Andres Freund | 2013-05-30 11:42:25 | extensible external toast tuple support |