[Raw Msg Headers][Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: BerkeleyDB via NFS

I GUESS that the problem would occur when changing the page file (i.e. 
reordering inside buckets), which needs a fairly large database to be an 
issue, and insertion activity. (I don't know if BDB coalesces buckets on 
deletion, and I may be saying something wrong :-)

As they say, my 0.02

Mariano Absatz wrote:

> 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'?
> El 19 Mar 2004 a las 3:41, Matti Aarnio escribió:
>>On Thu, Mar 18, 2004 at 05:48:36PM -0300, Mariano Absatz wrote:
>>>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

Carlos G Mendioroz  <tron@huapi.ba.ar>  LW7 EQI  Argentina

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