[DGD] DGD and *dbm

Shentino shentino at gmail.com
Mon Jul 21 22:25:50 CEST 2008


What about writing a "VFS" type thingy that holds all the data in
memory until it can be flushed with a 0-second callout?

I was planning something like this to work around the "no writes in
atomic code" part.  Where I would treat the underlying filesystem as a
fancy yet simple block device wherein I could flush data and cache it
as needed.  Sorta like the way the linux kernel deals with hard disks
and whatnot with its icache and dcache.

But, hearing about this new "fs hostile" (and by implication, network
daemon hostile) gives me the shivers.

On Mon, Jul 21, 2008 at 12:11 PM, Felix A. Croes <felix at dworkin.nl> wrote:
> bart at wotf.org wrote:
>
>> Seeing how I keep (to me useful) logs around that are many megabytes large,
>> keeping those in an object would for what I understand impact swapping
>> performance for that object. Am I mistaken? or is this simply far less of a
>> concern with DGD/MP?
>>
>> Trying to think of a workable data model for this makes me come up with a
>> number of variations, all of which end up in some nested array or an array of
>> mappings if it has to scale to an imho reasonable size.
>>
>> What is your suggestion for this?
>
> Nested arrays would still all be in the same object.  It would be best
> to store data in several objects, each filled up to a maximum log size.
> That way, only the most recent object will be modified by new log
> entries, while the others remain swapped out until someone accesses
> them all (which presumably happens less often).
>
> Regards,
> Dworkin
> ___________________________________________
> https://mail.dworkin.nl/mailman/listinfo/dgd
>



More information about the DGD mailing list