gnunet-developers
[Top][All Lists]
Advanced

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

[GNUnet-developers] no space free on GNUNET_HOME device


From: Milan
Subject: [GNUnet-developers] no space free on GNUNET_HOME device
Date: Mon, 08 May 2006 22:48:46 +0200
User-agent: Mozilla Thunderbird 1.0.7 (X11/20051017)

During insertion, I got these errors :

mai 08 20:50:02 Failure at uri.c:184.
mai 08 20:50:02 Assertion failed at upload.c:193.

I don't know if both are related to this bug, but I discovered that it was caused by a GiB/GB problem : my GNUNET_HOME is on a 3 GiB disk, so I specified 3000 in configuration, an it was about 2900 MB. Not such a serious issue, but still a stupid error of conversion...
So I have three questions :
1) Couldn't this error message be more explicit ? I understand you will to keep many failures uncommented to help translators and not lose time for little breaks, but this error seems to be important and not so exotic.

2) Should the usable space indication be in GB or in GiB ? Gnome uses GiB, df GB, so i'ts difficults ot choose. But it would maybe be better to use GiB : if you type 3072 in this field (because you believe it's GB and because you have 3 GB), some bytes will not be used, but no memory problem will appear. But if the conf file uses GB, if you type 3000 (because you believe it's GiB as I did without caring), you will get some trouble. This is why I think we could change it to GiB to avoid stupid errors.

2) I notice that it's a little complex to resize a DB on a separate hard disk, because gnunet-update need some free space to work and resize the DB lower. I had to move some shared files that were copied to this directory (I wasn't aware of this, but it's cool). So shouldn't too these copied (not symlinked) files be taken in account in the quota ? I'm thinking of my configuration for example : I don't want my DB to be corrupted because I indexed too many files that were copied. In general, the user just cares about the space GNUnet will take *in addition of what his personal files use*.


A little long discussion, but it would be good to avoid trouble in this domain before users are many, this is likely to frighten an average user because of simple quota issues.




reply via email to

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