Thanks for your responce!
On 月, 27 4月 2015 at 12:46:12 JST,
Howard Chu wrote:
> Interesting, thanks for the contribution. Looks like there is no
> manpage though, do you have one?
I will write it soon :p
> > Some note:
> > * slapadd, slapcat, slapindex will works.
> > * LDAP BIND, ADD, DELETE, SEARCH will works.
> How well does it work, good enough to run benchmarks now?
I have just tested on virtual machine, back-wt LDAP ADD(with single
thread) is 20-30x times faster than back-bdb.
I'm looking forward to benchmarking with many thread.
I'll publish benchmarks just when I get high spec machine.
> > * WiredTiger is not support multiprocess access yet.
> > It mean that we can't to do slatcat while running slapd.
> > It will be supported in the future.
> You should use alock in the meantime then, to prevent multiprocess access.
WiredTiger is planning to implement RPC for multiprocess access.
I think it will communicate with unix domain socket.
I'm planning to use the feature to avoid multi process locking.
Open Source Solution Technology Corporation
HAMANO Tsukasa <hamano(a)osstech.co.jp>
fingerprint = 2285 2111 6D34 3816 3C2E A5B9 16BE D101 6069 BE55
As you might've heard, Gitorious is shutting down on 15th May.
Maybe we start should look for a new home for the projects at
https://gitorious.org/mdb - do you guys have a plan for this?
I have made a tiny modification to the ppolicy-module. The aim is to
go easy on people who forgot their password, or forgot to deploy their
recently changed password to all devices (think of laptops,
smartphones, etc.). Whenever a login fails due to a invalid password,
the ppolicy-module will count this as a failure. After a configurable
number of password failures in a given time, ppolicy will take action
and - for example - lock the acount. I have tried to tweak this
behaviour: When the password is found in the password history, the
ppolicy-module will not count this as a password failure. If anyone is
interested in this, please find the attached patch which also includes
a working example configuration/testcase.
Florian Hercher | Hochschulrechenzentrum | Philipps-Universität Marburg
Hans-Meerwein-Str. 6, 35032 Marburg | fon +49-(0)6421-28-21036
Apologies if this arrives twice, I sent it once two days ago before
subscribing to the list and it hasn't appeared yet so I'm resending after
Memory mapping files on Windows requires the file size to match the size of
the memory mapped region however in the current implementation this
requires creating a file the full size of the environment which may be much
larger than the actual amount of data in the database.
This patch creates the database as a sparse file on Windows. Windows
Explorer will report the file size as the size of the entire memory mapped
region but the size on disk will be proportional to the size of committed
data in the database. This can be checked by checking the "size on disk"
property of the file.
Let me know if this is posted incorrectly, otherwise feel free to modify
the patch in whatever way is necessary for approval.
Eric thank you I would have never considered that as an issue.
I tried out your code and saw the problem.
You saved me going down a rabbit hole.
On Thu, Apr 2, 2015 at 5:33 PM, Eric Wong <e(a)80x24.org> wrote:
> James Rouzier <rouzier(a)gmail.com> wrote:
> > Hey Guys,
> > I am working on a proof of concept of a simple key value store service
> > using lmdb as the back end.
> > I am using sendfile to avoid an extra copy.
> Be careful if you're overwriting any data in LMDB.
> zero-copy sendfile means any data queued up in the kernel will be
> subject to modifications as the underlying file is updated, so your
> client may se data it was not intended to see.
> I wanted to do the same thing as you last year but ended up writing a
> patch to the sendfile manpage instead:
I am working on a proof of concept of a simple key value store service
using lmdb as the back end.
I am using sendfile to avoid an extra copy.
I accomplished this by creating function to extract get the mmap ptr from
the env so I can calculate the offset of data.
I figured that function might be useful to the bigger community.
If it does not fit in the bigger vision of lmdb it is fine not to include
You will find the diff attached.