Re: (ITS#7715) SIGBUS when mdb is configured with writemap

[hyc@symas.com]

Howard Chu wrote:
> Željko NejaÅ¡miÄ? wrote:
>> On Fri, Oct 4, 2013 at 10:26 AM, <hyc@symas.com> wrote:
>>>
>>> Thanks. So far the output shows nothing out of the ordinary. Can you also
>>> provide the output for:
>>>       ls -l /opt/openldap/var/openldap-data
>>
>> root@spr101:~ $ ls -ahl /opt/openldap/var/openldap-data
>> total 100K
>> drwxr-xr-x. 2 openldap openldap 4.0K Oct  4 07:54 .
>> drwxr-xr-x. 4 openldap openldap 4.0K May 28 08:49 ..
>> -rw-------. 1 openldap openldap  88K Oct  4 07:44 data.mdb
>> -rw-------. 1 openldap openldap 8.0K Oct  4 07:54 lock.mdb
>
> Something is flaky with your installation. As I wrote in my previous email,
> LMDB always sets the file size to match your mapsize, to avoid this SIGBUS
> issue. Your mapsize is 38654705664 (36GB) but the data.mdb filesize is only
> 88K, it should be 36GB. You must have some other process running that is
> truncating the file; there is nothing in OpenLDAP's code that would cause this
> behavior.

I take this back, this is a bug introduced in liblmdb 0.9.8; it is only 
setting the filesize on a newly created DB. If you had an existing DB and 
added writemap to your configuration after the fact, the DB size wasn't 
getting set. The fix is simple, and is now in git branch mdb.master.
>
>> root@spr101:~ $ ps -efa | grep slapd
>> openldap 44012     1  0 07:54 ?        00:00:01
>> /opt/openldap/libexec/slapd -h ldap:/// ldapi:/// -F
>> /opt/openldap/etc/openldap/slapd.d -g openldap -u openldap
>>
>> root@spr101:~ $ mount | grep sdb1
>> /dev/sdb1 on /opt type ext4 (rw,noatime,nobarrier,data=ordered)
>> Do note that we did load testing on ext2 and ext4, with both being
>> tweaked and not, and as far as I recall, every combination of
>> parameters causes the problem; I will try to reproduce it on
>> ext{2,3,4} with default mounting parameters. Almost forgot, we did
>> tests using tmpfs also, with the same outcome. The whole /opt was used
>> as a mount point for the tmpfs.
>>
>> root@spr101:~ $ fdisk -lu /dev/sdb1
>> Disk /dev/sdb1: 400.0 GB, 400027127808 bytes
>> 224 heads, 56 sectors/track, 62284 cylinders, total 781302984 sectors
>> Units = sectors of 1 * 512 = 512 bytes
>> Sector size (logical/physical): 512 bytes / 512 bytes
>> I/O size (minimum/optimal): 512 bytes / 512 bytes
>> Disk identifier: 0x00000000
>>
>> gparted doesn't seem to be complaining about SSD block alignment:
>> root@spr101:~ $ parted /dev/sdb1 align-check opt 1
>>
>> Another thing I'll be trying is making a partition with different
>> alignment parameters to see if any change occurs; tried using a
>> different scheme, but that hasn't produced a a change in behavior.
>>
>>>
>>> Note from the mmap(2) manpage:
>>>
>>>           Use of a mapped region can result in these signals:
>>>
>>>           SIGSEGV
>>>                  Attempted write into a region mapped as read-only.
>>>
>>>           SIGBUS Attempted access to a portion of the buffer that does not
>>> correspond to the file (for  example,  beyond
>>>                  the end of the file, including the case where another process
>>> has truncated the file).
>>>
>>> LMDB always sets the size of the file when using the WRITEMAP option, so the
>>> SIGBUS condition should never happen. The pointers in your gdb output are all
>>> within the bounds of the map and mapsize you configured.
>>>
>>> What filesystem type is the data directory stored on? This is looking more
>>> like a kernel or filesystem bug than anything else.
>>>

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/