On Tuesday 16 June 2009 19:16:53 Evan Daniel wrote: > In either case, you have to let it finish. This is a slow process, > and requires enough space to hold both the old and new store on the > disk at the same time.
I don't think that is true for resizes? It's true for converting from one store type to another, but afaik you only need the maximum of the two sizes for resizes? > Setting preallocate datastore and resize store > on node start both to true will make it run faster, though the node > won't be usable during the resize. > > If you want it to run faster, the only solution I know of is to use a > faster disk. Unfortunately, the resize does a lot of random io, > rather than sequential, which makes it very slow. Yep. This is the tradeoff we made when switching from bdbje. Slightly faster on the network level, far more reliable, less memory churn, generally faster, but because it's a direct, lossy hashtable, resizing and conversion take *ages*. PS make sure your disk is connecting via USB2 not USB1! > > Evan Daniel > > On Tue, Jun 16, 2009 at 2:03 PM, <bbac...@googlemail.com> wrote: > > Now, after the reset to 90GiB, the node starts again with the migration: > > > > INFO | jvm 1 | 2009/06/16 20:00:37 | CHK-cache cleaner in progress: > > 0/1534443 > > > > Had to stop it. When there is no solution I have to delete the store > > and start a new one? > > > > > > ---------- Forwarded message ---------- > > From: <bbac...@googlemail.com> > > Date: Tue, Jun 16, 2009 at 19:43 > > Subject: How to increase the store? > > To: email@example.com > > > > > > I wanted to increase my datastore from 90 to 100GiB. Changed the setting, > > and set 'preallocate datastore' to false (also tried with true, same > > result). > > Shortly after restart the node starts to access each single key: > > .... > > INFO | jvm 1 | 2009/06/15 07:10:23 | PUBKEY-cache cleaner in > > progress: 1376135/1380999 > > INFO | jvm 1 | 2009/06/15 07:12:00 | CHK-cache cleaner in > > progress: 0/1380999 > > .... > > > > The CHK process ran for more than 14 hours, and then it didn't even > > reach 30% progress. > > I had to stop the migration. I set the node size back to 90GiB, and > > now my cache utilization is > > at 5,5% (before it was 99%). So most of the data is gone. But however, > > how can I increase > > the store without the never-ending migration? > > > > FYI: I run freenet on a laptop, the store is on an external USB hard disk. > > > > -- > > __________________________________________________ > > GnuPG key: (0x48DBFA8A) > > Keyserver: pgpkeys.pca.dfn.de > > Fingerprint: > > 477D F057 1BD4 1AE7 8A54 8679 6690 E2EC 48DB FA8A > > __________________________________________________ > > > > > > > > -- > > __________________________________________________ > > GnuPG key: (0x48DBFA8A) > > Keyserver: pgpkeys.pca.dfn.de > > Fingerprint: > > 477D F057 1BD4 1AE7 8A54 8679 6690 E2EC 48DB FA8A > > __________________________________________________ > > _______________________________________________ > > Support mailing list > > Support@freenetproject.org > > http://news.gmane.org/gmane.network.freenet.support > > Unsubscribe at > > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support > > Or mailto:support-requ...@freenetproject.org?subject=unsubscribe > > > _______________________________________________ > Support mailing list > Support@freenetproject.org > http://news.gmane.org/gmane.network.freenet.support > Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support > Or mailto:support-requ...@freenetproject.org?subject=unsubscribe > >
Description: This is a digitally signed message part.
_______________________________________________ Support mailing list Support@freenetproject.org http://news.gmane.org/gmane.network.freenet.support Unsubscribe at http://emu.freenetproject.org/cgi-bin/mailman/listinfo/support Or mailto:support-requ...@freenetproject.org?subject=unsubscribe