On Wed, Apr 24, 2013 at 12:21 PM, Sašo Kiselkov <skiselkov...@gmail.com>wrote:

>
> Just as a quick follow-up on this, when I manually undefine
> HAVE_POSIX_FALLOCATE, which makes SQLite fall back to the
> truncate-and-write implementation, everything works fine.
>
> ZFS has been the filesystem of choice for SunOS-based systems for about
> the last 5 years now, is becoming that for FreeBSD as we speak, and is
> quickly gaining ground on Linux. The absence of support for
> posix_fallocate() on ZFS kind of makes sense, since copy-on-write
> filesystems cannot keep the posix_fallocate promise:
>
>
> http://pubs.opengroup.org/onlinepubs/009696799/functions/posix_fallocate.html
> "If posix_fallocate() returns successfully, subsequent writes to the
> specified file data shall not fail due to the lack of free space on the
> file system storage media."
>


SQLite is using posix_fallocate() to allocate space for a region of shared
memory obtained using mmap().  If the space cannot be preallocated, then
when we use the mmapped region and an attempt is made to allocate the space
and the filesystem is full, we'll get a SIGBUS signal.

So what you seem to be saying is that if you (1) use ZFS and (2) use mmap()
and (3) your filesystem fills up, then there is nothing your application
can do to avoid a SIGBUS.  Am I missing something here?


-- 
D. Richard Hipp
d...@sqlite.org
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to