Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Store netDB and peerProfiles in a key-value storage #1141

Open
l-n-s opened this issue Mar 5, 2018 · 6 comments
Open

Store netDB and peerProfiles in a key-value storage #1141

l-n-s opened this issue Mar 5, 2018 · 6 comments

Comments

@l-n-s
Copy link
Member

l-n-s commented Mar 5, 2018

To address the issue of high disk usage by NetDb and PeerProfiles, which is especially bad for devices with low flash and/or RAM (when using tmpfs), like cheap routers, Raspberry Pi and Anrdoid SDCard.

@orignal
Copy link
Contributor

orignal commented Mar 5, 2018

I see too different problems:

  1. Excessive disk space usage
  2. Excessive I/O operations

While 1. could be implemented with any approach using a single big file instead bunch of small, 2. is a subject for discussions and suggestion.
Using any additional libraries wouldn't solve 2. automatically because amount of data remains the same.

@hakunamtu
Copy link

As I can see, some sources of (write)I/O operations in NetDb are storing info on updated routers and storing profiles for unreachable ones. One of solutions is to store this information in some sort of buffer, from which records are flushed on a timeout or on repletion. I don't know, how often routers become reachable in a short time after being unreachable, maybe this buffer could be a queryable part of a new storage.

@hakunamtu
Copy link

Another way to reduce disk I/O might be making netDb and peerPorfiles disk synchronisation interval configurable. It will allow users to make disk writes/RAM consumption tradeoffs themselves, interval value 0 might stand for no sync at all (don't know what would be better to do with peerProfiles in this case: maybe, don't keep them at all, maybe keep them in size-restricted LRU cache) . If it's possible to add external dependency, I suggest TDB: it's small (43k) and widely used (because part of samba). If not, I will be glad to write custom storage (probably, based on HAMT, since all keys are equal in size), though this effort will likely end up in reimplementation of most of already existing solutions' features.

@orignal
Copy link
Contributor

orignal commented Jan 8, 2019

Go ahead and implement these config params

@hakunamtu
Copy link

Synchronization interval option: #1285
What about TDB storage backend?

@orignal
Copy link
Contributor

orignal commented Jan 20, 2019

if you wish try to implement a flat file (tar like) for entire storage. Meaning you store all files sequentially in one shot.
But without additional dependencies, please.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants