help-gnunet
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Help-gnunet] seperate disk quota for migrated content


From: Christian Grothoff
Subject: Re: [Help-gnunet] seperate disk quota for migrated content
Date: Fri, 3 Oct 2003 18:16:40 -0500
User-agent: KMail/1.4.3

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 03 October 2003 06:00 pm, Benjamin Paul Kay wrote:
> I'd like to allow content migration on my node. After running freenet for
> some time, I appreciate how content migration can benefit the entire
> network.
>
> The problem:
> gnunet.conf only lets me specify one disk quota. It claims that content
> that is indexed only (which mine is) does not take up disk quota, but I
> quickly learned that to continue to index files I must make my disk quota
> bigger. Migrated content also uses the disk quota. So if I leave content
> migration on, I can no longer index files. If I leave content migration on
> long enough to fill the quota, turn it off, and then increase the quota the
> benefits of content migration are largely negated. Is there any way to
> specify one quota for content I insert/index and another for migrated
> content?
>
> Thanks!

Indexed content does take away some storage space, I would guess roughly about 
10% of the size of the indexed files, but that's just an approximation and it 
also depends on the type of database that you are using.  The documentation 
was supposed to indicate that it uses much less space than full insertion.  
If you can point me to the ambiguous passage, I'll certainly try to improve 
that.

I don't see that it would make too much sense to have 2 quota options.  
Especially since gnunet-insert does *remove* "worthless" migrated content in 
favour of indexed content.  You should only hit the quota if your indexing 
surpasses the quota disregarding the migrated content (assuming that the 
priority given for locally indexed content is sufficiently high, the default 
of 50 should be fine).

Aside of that I consequently don't understand the need for such an option, it 
would be quite difficult to implement this type of segregation of DB quotas 
efficiently (without ending up with 2 DB lookups per query instead of one).

Christian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE/fgNY9tNtMeXQLkIRAheYAJ9Is5/KbrkGT6vJC9ND1KYpLmAV/gCfSQ0O
uy7QwUVb8W1hEIZZiAatXEE=
=yWds
-----END PGP SIGNATURE-----





reply via email to

[Prev in Thread] Current Thread [Next in Thread]