[freenet-dev] [freenet-cvs] r19306 - trunk/freenet/src/freenet/store

[Matthew Toseland]

Obviously a big change such as that should be kept on a branch for the time 
being. Please create one when you have something to commit.

On Tuesday 15 April 2008 17:13, Matthew Toseland wrote:
> On Tuesday 15 April 2008 14:29, Daniel Cheng wrote:
> > On Tue, Apr 15, 2008 at 6:33 PM, Matthew Toseland
> > <toad at amphibian.dyndns.org> wrote:
> > >
> > > On Tuesday 15 April 2008 01:16, Daniel Cheng wrote:
> > >  > On Tue, Apr 15, 2008 at 6:07 AM, Matthew Toseland
> > >  > <toad at amphibian.dyndns.org> wrote:
> > >  > > On Monday 14 April 2008 08:53, j16sdiz at freenetproject.org wrote:
> > >  > >  > Author: j16sdiz
> > >  > >  > Date: 2008-04-14 07:53:47 +0000 (Mon, 14 Apr 2008)
> > >  > >  > New Revision: 19306
> > >  > >  >
> > >  > >  > Modified:
> > >  > >  >    trunk/freenet/src/freenet/store/BerkeleyDBFreenetStore.java
> > >  > >  >    trunk/freenet/src/freenet/store/FreenetStore.java
> > >  > >  >    trunk/freenet/src/freenet/store/RAMFreenetStore.java
> > >  > >  > Log:
> > >  > >  > change javadoc and RAMFS.put() to match BDBFS.put() behaviour
> > >  > >
> > >  > >  Eh? Did you actually read BDBFS.put() ?
> > >  >
> > >  > Yes, what it do is a StorableBlock.equals(), which doesn't check the
> > >  > actual data afaik.
> > >
> > >  And now you don't even do that in RAMFS? Or am I missing something? PS 
it 
> does
> > >  check the data.
> > 
> > Revert it then.
> > 
> > I am working on a new datastore, which have pluggable index and file 
> storage.
> 
> There should be a BDBFS plugin. Then we can get rid of the old BDBFS code.
> 
> But also an index-in-RAM plugin etc... it would open up the way to lots of 
> different backends, maybe one of them will be both stable and fast. :)
> > 
> > Do you think online database reconstruction is doable? That would need 
> putting
> > the database into a readonly mode temporary. Not sure if our routing 
> algorithm
> > can handle that.
> 
> This is an interesting idea. It would in all likelihood be detectable 
> remotely; it would result in data being rerequested that didn't need to be 
> rerequested (freesites if the user browses them, but especially persistent 
> downloads). Having said that, some time soon after 0.7.0 ships we will have 
> proper persistent downloads... and the datastore is remotely probeable right 
> now anyway. In the future, we'll have a separate, possibly ephemeral, 
> client-layer-only cache, for freesites etc.
> 
> Certainly it wouldn't break the routing algorithm, although it would 
introduce 
> some noise. It's simply a question of whether it would have any security 
> impact. It may be a good idea, certainly it would improve usability. 
Although 
> just the recent changes to reconstruction plus not reading the store file 
> unless we need to should speed up reconstruction considerably.
> > 
> > Regards,
> > Daniel Cheng
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://emu.freenetproject.org/pipermail/devl/attachments/20080415/94f331ff/attachment.pgp