Hi Johannes,
1) Yes, we configured a storage path too. And yes, we do have the devices turning off from time to time in an uncontrolled way. That should be the problem. We will be changing the source code of the daemon so that it erases all the files in the blob folder once the daemon is launched.
2) When you say dtnd was memleak checked, that refers only to real memory, right? Did you make some measurements regarding virtual memory as well? We are currently working with industry partners on a huge testbed, with hundreds of vehicles equipped with small memory devices that can host IBR-DTN. It is an extremely sensitive testbed running multiple services and experiments, and so we are required to be extremely careful with everything that may cause any kind of malfunction of the devices. We were alerted of the very high values of virtual memory by dtnd and asked if we could check and solve that issue. It may not be really an issue, but neither we nor our partners are familiar enough with issues of virtual memory to guarantee that such high values will not pose a risk to the testbed.
Thank you,
Romeu
On Fri, Jun 6, 2014 at 2:50 PM, Johannes Morgenroth < morgenroth@ibr.cs.tu-bs.de> wrote:
Hello Romeu.
- Did configured a storage path too?
Cleaning the blob folder on each reboot is pretty fine. Orphaned files in that directory should only exist if the daemon is not shutdown properly or unexpectedly. Is that the case? Do you turn off the device without shutting the daemon down?
- I can not tell you why the virtual memory increases. The dtnd is
memleak checked via valgrind, which reports no leaks. Moreover, the software has been tested on platforms with only 32 MB of RAM and even there, the dtnd is working properly. Thus I am not sure, if the amount of assigned virtual memory is really an issue. Do you have any reasons why you are consider that as an issue?
Kind regards, Johannes
Am 06.06.2014 11:57, schrieb Romeu Monteiro:
Hi,
We are using IBR-DTN in a vehicular testbed and we currently have 2 issues we are tackling and we would appreciate if you can give us some input about them:
- Blobs folder
As far as we know, this folder's goal is only to host files temporarily. However, after a long time running IBR-DTN (several days) we have seen it increase its size and it has reached 28 MB. It contains many files, many of them old files. We cannot have such an amount of storage being used for this folder, and we would like to correct whatever is causing this. For now we are cleaning the files in folder when the devices boot, but we do not want that as a permanent solution.
- Virtual Memory
We have seen that IBR-DTN does not take up a lot of real memory and we did not have problems with that, but as time goes by we see the daemon taking more and more virtual memory, growing into the several hundreds of percent of the real memory. We are not sure if that might cause problems as time goes by so we would like to prevent the virtual memory from increasing to such enormous values.
Do you have ideas or suggestions on how to tackle these 2 issues?
Thank you very much,
Romeu Monteiro
-- !! This message is brought to you via the `ibr-dtn' mailing list. !! Please do not reply to this message to unsubscribe. To unsubscribe or adjust !! your settings, send a mail message to ibr-dtn-request@ibr.cs.tu-bs.de !! or look at https://mail.ibr.cs.tu-bs.de/listinfo/ibr-dtn.