[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: NFS-shared LMDB?

Hallvard Breien Furuseth wrote:

Howard Chu writes:

It occurs to me that there is the potential to support an interesting use case
with LMDB when the database resides on remote shared storage. In the context
of slapd, you could run multiple read-only slapds concurrent with a single
read-write slapd on a single database.


Not quite... only slap tools open an MDB (or BDB) environment in
read-only mode, as far as I can tell.  slapd always opens read/write.
The "readonly" slapd.conf option only restricts LDAP operations.
We can certainly change this for back-mdb if desired. Add a new config keyword for this purpose, etc. 


Also there's the issue of agreeing who gets to create (and maybe reset?)
a lockfile.  IIRC that's where people use mkdir for atomic NFS behavior,
unless modern NFS fixes that.  Though maybe it's enough to omit O_CREAT
for the the lockfile in the read-only slapds, if that gets supported.
I would expect the single writing slapd to do all environment initialization. A reading slapd would require the environment to already exist. 


The current liblmdb would need a couple small modifications to make this safe
- an option to use fcntl(LOCK) when obtaining a reader slot, and an msync()
when writing to a reader slot, to force reader lock table changes back to the
server before progressing on a read txn.


And maybe another sync call for the writer to pick the change up before
progressing?  OTOH readers may not need to await the msync() if an older
reader in the same process is still live.


Yeah I don't think that would be necessary.

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