| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Greg Smith <greg(at)2ndQuadrant(dot)com> |
| Cc: | Jon Nelson <jnelson+pgsql(at)jamponi(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: fallocate / posix_fallocate for new WAL file creation (etc...) |
| Date: | 2013-06-30 18:01:53 |
| Message-ID: | 1372615313.19747.13.camel@jdavis |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, 2013-05-28 at 22:10 -0400, Greg Smith wrote:
> I was just thinking of something to run in your test program, not
> another build time check. Just run the new allocation sequence, and
> then check the resulting WAL file for a) correct length, and b) 16K of
> zero bytes. I would like to build some confidence that posix_fallocate
> is operating correctly in this context on at least one platform. My
> experience with Linux handling this class of functions correctly has
> left me skeptical of them working until that's proven to be the case.
As I understand it, you are basically asking if posix_fallocate() works
at all anywhere.
Simple test program attached, which creates two files and fills them:
one by 2048 8KB writes; and another by 1 posix_fallocate of 16MB. Then,
I just cmp the resulting files (and also "ls" them, to make sure they
are 16MB).
Passes on my workstation:
$ uname -a
Linux jdavis 3.5.0-34-generic #55-Ubuntu SMP Thu Jun 6 20:18:19 UTC 2013
x86_64 x86_64 x86_64 GNU/Linux
Regards,
Jeff Davis
| Attachment | Content-Type | Size |
|---|---|---|
| fallocate.c | text/x-csrc | 341 bytes |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeff Davis | 2013-06-30 18:11:58 | Re: fallocate / posix_fallocate for new WAL file creation (etc...) |
| Previous Message | Pavel Stehule | 2013-06-30 17:08:07 | Re: review: Non-recursive processing of AND/OR lists |