On Fri, Mar 28, 2003 at 03:06:41PM +0000, Gordan Bobic wrote: > Hi, Matthew. > > Please forgive me for contacting you off the list, I hope that is OK. I > didn't > think this is something that would be hugely useful to the general user > base...
This should probably have gone to devl at freenetproject.org. Theoretically, tech at freenetproject.org, but that has lately become largely non-functional. > > I've got a question - not necessarily a sensible one for normal "client" use, > but than again, I am doing this for a research project. :-) > > Is it possible to run multiple Freenet node daemons with the same physical > data store? I am thinking about setting up multiple nodes into a parallel > cluster. The data store file system remotely mounted using NFS or Coda, and > then multiple physical machines could run separate Fred instances but share > the data store. This would provide higher throughput in terms of requests > that could be handled by the cluster (as opposed to a single node), but there > would be no space overhead of duplicated data when running multiple nodes. Hrmm. In a word, no. In a sentance, not without adding additional synchronization to Fred. The problem is primarily that each node needs to maintain its own datastore RAM structures, for example a full LRU list of the store, an up to date space usage counter, etc... I'm not sure that duplicated data is a big problem, given the estimated size of Freenet... but if you could get some empirical data, that would be cool. > > Does Fred use flock() during read/write operations to the file store? Or is > there a file locking method that is entirely internal to the node? I am > guessing that if flock() is used by each thread, multiple nodes could access > the same physical data store without any problems, but I would ideally like a > confirmation of that. Nope. What Fred does is the following: All files in store/[0-9a-f][0-9a-f]/ are finished, full files - they can be read, deleted to free space, and that's it. Files in store/temp/ are in-progress - they can be circular buffers, in which case they are deallocated as soon as the transfer in question finishes, or they can be regular files, in which case they are written to progressively by one thread and read by others. They will never be written in the middle. There are also temp files from higher level stuff allocated in store/temp/, because it is convenient to do so. > > And in case anyone is wondering what clustering is supposed to achieve, I am > guessing that it would enable more CPU power to be thrown at a node without > suffering the data store file duplication. Obviously, the store encryption I'm not sure that duplication is a big problem, but could be persuaded one way or the other by empirical evidence. > keys would need to be shared, but what about the node's public/private keys? > I am guessing that given the recent additions of ARK, each node would have to > use it's own, separate key, but I am not sure how/if this would be compatible > with sharing the data store between nodes... Well... routing relies on nodes specializing in a particular area of the keyspace, this means if nodes share the datastore they should ideally share the same identity, contact details etc, and just have round-robin DNS or some random-redirect process... > > Regards. > > Gordan > -- Matthew Toseland toad at amphibian.dyndns.org/amphibian at users.sourceforge.net Full time freenet hacker. http://freenetproject.org/ Freenet Distribution Node (temporary) at http://80-192-4-36.cable.ubr09.na.blueyonder.co.uk:8889/qSRACKEd0DQ/ ICTHUS. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20030328/dab0bd99/attachment.pgp>
