OpenLDAP
Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest

Viewing Incoming/8783
Full headers

From: serg.brester@sebres.de
Subject: LMDB on network share path is inconsistent after put data
Compose comment
Download message
State:
0 replies:
1 followups: 1

Major security issue: yes  no

Notes:

Notification:


Date: Wed, 06 Dec 2017 16:19:34 +0000
From: serg.brester@sebres.de
To: openldap-its@OpenLDAP.org
Subject: LMDB on network share path is inconsistent after put data
Full_Name: Sergey Brester
Version: all, also latest master 4d5e2d2a2ac38b9d56b6ba73187c325024718167
OS: windows
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (80.154.98.131)


If I save many data into LMDB file placed in network share, only the latest key
is really in the database after reopen.
Tested single threaded (1 process, 1 thread). No matter which flags supplied to
mdb_env_open...

So repeateable writing of 10 keys (total 960 times) should result in:

Target-state: 10 keys
{
  "some-key-0": "951",
  "some-key-1": "952",
  "some-key-2": "953",
  "some-key-3": "954",
  "some-key-4": "955",
  "some-key-5": "956",
  "some-key-6": "957",
  "some-key-7": "958",
  "some-key-8": "959",
  "some-key-9": "960"
}

After reopen of database you'll see:

Actual-state: 1 key
{
  "some-key-9": "960"
}

Doing the same on local drive works fine and actual state is equal target
state.

Followup 1

Download message
Subject: Re: (ITS#8783) LMDB on network share path is inconsistent after put
 data
To: serg.brester@sebres.de, openldap-its@OpenLDAP.org
From: Howard Chu <hyc@symas.com>
Date: Wed, 6 Dec 2017 16:40:10 +0000
serg.brester@sebres.de wrote:
> Full_Name: Sergey Brester
> Version: all, also latest master 4d5e2d2a2ac38b9d56b6ba73187c325024718167
> OS: windows
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (80.154.98.131)
> 
> 
> If I save many data into LMDB file placed in network share, only the latest
key
> is really in the database after reopen.

The docs explicitly state not to use LMDB with remote filesystems.
http://www.lmdb.tech/doc/

Closing this ITS.

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


Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest


The OpenLDAP Issue Tracking System uses a hacked version of JitterBug

______________
© Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org