Hi,
On 2013-09-04 11:15:37 -0400, Stephen Frost wrote:
> * Andres Freund (andres@2ndquadrant.com) wrote:
> > I'd vote for adding zeroing *after* the fallocate() first. That's what's
> > suggested by kernel hackers and what several other large applications
> > do. As it looks like it's what we would have to do if we ever get to use
> > fallocate for relation extension where we would have actual benefits
> > from it.
>
> Does that actually end up doing anything different from what we were
> doing pre-patch here? At best, it *might* end up using a larger extent,
> but unless we can actually be confident that it does, I'm not convinced
> the additional complexity is worth it and would rather see this simply
> reverted.
It does end up with larger extents. That's why e.g. several of the
virtualization solutions do it for container files.
I was sceptical of the idea of using fallocate() for WAL file allocation
from the get go and voiced that repeatedly, but the argument was made
that it's a convenient testcase to familiarize ourselves with
fallocate(). As that argument won we should stick to it and learn the
ropes. Part of that is zeroing, so we should do that.
It's a single write() + error checking, so I don't really see much
complexity that way.
> One might ask why the kernel guys aren't doing this themselves or
> figuring out why it's necessary to make it worthwhile.
So, if I understood Ted correctly the reason it's slower is that
fallocate() onl marks the extents as containing 'zero' without actually
touching the data. When then a partial write into the area is done the
rest of the page has to be actively zeroed on disk.
I am not sure that explains all the slowdown, but given that according
to tests published in this thread, the additional zeroing helps to get
at the former + small win state...
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services