BerkeleyDB via NFS (was: Re: smtp-policy.db and other bdb's via NFS)

["Mariano Absatz" <zmailer@lists.com.ar>]

OK... maybe I'm too stubborn, but anyway, we did a small test running one 
daemon randomly inserting, modifying and deleting records in a BerkeleyDB 
4.2 hash database, while about 90 other processes were randomly reading 
records...

We got 6 search errors in about 1,000,000 reads... I could live with 
that... 

Does anyone have personal (or 3rd. party but actually known) case 
experience doing this and not working? or is it just a feelin'?

TIA

El 19 Mar 2004 a las 3:41, Matti Aarnio escribió:

> On Thu, Mar 18, 2004 at 05:48:36PM -0300, Mariano Absatz wrote:
> > Hi,
> > 
> > I think I asked this before here and the only answer came from Eugene, 
> > telling me to use cfengine.
> > 
> > However, I have a new case where cfengine will not be as effective...
> > 
> > Has anyone experience using smtp-policy.db, userdb.db, routes.db and the 
> > like in a fast NFS mount?
> > 
> > The databases would NEVER be modified from the mail servers, but from a 
> > central server (that has them also NFS mounted), and most of them will 
> > actually be dinamically modified (not via 'newdb').
> 
>   Db-file recompile method (e.g. what  "zmailer newdb" does)  should be 
>   successfully autosensed over NFS, and handled in consistent manner.
> 
>   What will NOT be successfull is concurrent-data-store access in
>   Sleepycat DB.  Shared-memory segments don't fly over NFS very
>   nicely...
> 
>   What _might_ work is GNU GDBM shared writer access with its locking
>   schemes.  Things I faintly recall about it might allow successfull
>   shared access over NFS.  (fcntl locking, no shared memory things.)
>   Reading gdbm's documents:
>     Readers and writers can not open the `gdbm' database at the same time.
>   Oh, uh..   No can do.
> 
>   What COULD work (even handsomely) is RPC mode of Sleepycat DB.
>   However it will require additional code in the router system ..
>   .. and isn't supportable in smtpserver without considerable
>   modifying of "PARAM policydb" processing.    Hmm..  introducing
>   new dbtype, perhaps "sleepyrpc",  and 'file' parameter would then
>   point to configuration file with necessary parameters ?
>   The   lib/sleepycatdb.c  function collection isn't quite generic
>   enough to be used at present anywhere, but inside the router.
> 
>   I was entertaining an idea of replicating sleepycat db thru
>   its builtin replication support ("some" user code required!)
>   but that is rather over-complicated thing..

--
Mariano Absatz
El Baby
----------------------------------------------------------
If knowledge can create problems, it is not through
ignorance that we can solve them.
         -- Isaac Asimov


-
To unsubscribe from this list: send the line "unsubscribe zmailer" in
the body of a message to majordomo@nic.funet.fi