[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'?
>
> 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
>
--
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