이메일 #091 - #095

원본 출처: Satoshi - Sirius emails 2009-2011

이메일 #091

Date: Tue, 17 Nov 2009 03:41:26 +0000
From: Satoshi Nakamoto <[email protected]>
Subject: linux-0.1.6-test7
To: Liberty Standard <[email protected]>
Cc: Martti Malmi <[email protected]>

영어 원문

test 7:

Backup your data directory before running this, just in case.

Workaround for the Db::open/Db::close "Bad file descriptor" exception. 
Might also make the initial block download faster.  The workaround is to 
open the database handles and keep them open for the duration of the 
program, which is actually the more common thing to do anyway.  If we're 
not closing and opening all the time, the error shouldn't get a chance 
to happen.

The one exception is wallet.dat, which I still close after writing is 
finished so I can flush the transaction logs into the dat file, making 
the dat file standalone.  That way if someone does a backup while 
Bitcoin is running, they'll get a wallet.dat that is valid by itself 
without the database transaction logs.

This is a restructuring of the database handling, so we might find some 
new deadlocks.  Usually if it deadlocks, either the UI will stop 
repainting, or it'll stop using CPU even though it still says Generating.

이메일 #092

Date: Tue, 17 Nov 2009 16:57:26 +0000
From: Satoshi Nakamoto <[email protected]>
Subject: Re: Forum
To: [email protected]

영어 원문

[email protected] wrote:
> How about Drupal's forum functionality? Address: 
> https://174.143.149.98/drupal/. The CMS in general looks better and 
> simpler than TikiWiki. If the forum's not good enough, then we can of 
> course use a specialized forum software like phpBB.

Another issue I thought of with zetaboards: most free forum sites won't 
let you export the user account database if you want to move.  I don't 
know why I don't see any other software projects using a free forum, but 
I have to assume there might be a reason we would discover later.

If you can install phpBB3 on your VPS, that's probably the better option.

 From what I've seen on other forums, if the cost of bandwidth becomes 
an issue, a small Google Adwords (text links) at the top generates more 
than the cost of bandwidth even for very low value traffic like gaming. 
  This would be much higher value traffic well targeted for high paying 
gold merchant keywords and VPN hosts.  It could eventually be a valuable 
revenue stream you wouldn't want to give away to some free site.

I want to pre-announce some of the features in version 0.2 on the forum 
and try to get some anticipation going.  Even if hardly anyone else is 
posting, I have seen project forums where most of the posts are the 
author announcing what's going on with the latest changes.  Users can 
see progress going on, see that it's improving and supported and not 
abandonware.  It's a little like a blog in that case, but easier for 
users to use it as a searchable FAQ and better organized.  Whenever I 
google search software questions, most of the hits are forum posts.

이메일 #093

Date: Wed, 18 Nov 2009 03:31:39 +0200
From: [email protected]
To: Satoshi Nakamoto <[email protected]>
Subject: Re: Forum

영어 원문

I installed both phpBB3 and Simple Machines Forum, which are kind of
the market leaders among the open source forums. SMF's interface looks
better on the first look, especially the admin panel. What do you
think, shall we go with SMF or phpBB3?

이메일 #094

Date: Wed, 18 Nov 2009 03:50:24 +0200
From: [email protected]
To: Satoshi Nakamoto <[email protected]>
Subject: Re: Db::open/Db::close "Bad file descriptor" exception

영어 원문

Here's the logs in case they're still useful.

> I have an idea for a workaround, but it depends on what files the
> errors are on.  If you've accumulated several errors in db.log, could
> you send it to me? (even if it's rather simple and boring)  Is the file
> listed always blkindex.dat, or does it include addr.dat or wallet.dat
> too?

이메일 #095

Date: Wed, 18 Nov 2009 04:35:32 +0000
From: Satoshi Nakamoto <[email protected]>
Subject: Re: linux-0.1.6-test7
To: Liberty Standard <[email protected]>
Cc: Martti Malmi <[email protected]>

영어 원문

Finally an easy one.  I see a way that could happen on a long operation 
such as the initial download.  The TryLock bug is unrelated to the db 
stuff.  Fix will be in test8.

I've been able to reproduce the db::open/close exception 3 times now on 
32-bit linux by hitting it with a continuous flood of non-stop requests. 
  It looks like even periodically closing the wallet.dat database to 
flush it gets the db::close exceptions.  I'm disabling the wallet flush 
feature on Linux.  On Linux we'll never close a database handle until 
we're ready to exit.  So far with this disabled, no exceptions.

I'm also implementing the orderly initial block download.  Instead of 
naively requesting all the blocks at once, it'll request batches of 500 
at a time.  This way, it'll receive the blocks before the retry timeout, 
so it shouldn't go requesting it from other nodes unless it actually 
doesn't receive them or it's too slow.  The change is in the requestee's 
side, so this functionality won't be visible until your initial block 
download is coming from a node that has the new version.

I'm going to test this some more before sending test8.

Liberty Standard wrote:
> I started with a fresh data directory with test7. Blocks started to 
> download much faster. It only took about 15 seconds where it took a few 
> minutes previously with the Linux build. It crashed once while it was 
> downloading blocks with the following message in the terminal.
> 
> ../include/wx/thrimpl.cpp(50): assert "m_internal" failed in TryLock(): 
> wxMutex::TryLock(): not initialized [in child thread]
> Trace/breakpoint trap
> 
> I've included my log file, but I forgot to back it up before restarting 
> bitcoin, so I'm not sure at what point in the log file the crash occurred.
> 
> Fortunately I haven't encountered the segmentation fault yet. The 
> frequency of segmentation faults in the previous builds varied quite a 
> bit, so I'll keep running it and let you know if i run into any problems.
> 
> 
> 
> On Tue, Nov 17, 2009 at 5:41 AM, Satoshi Nakamoto <[email protected] 
> <mailto:[email protected]>> wrote:
> 
>     test 7:
> 
>     Backup your data directory before running this, just in case.
> 
>     Workaround for the Db::open/Db::close "Bad file descriptor"
>     exception. Might also make the initial block download faster.  The
>     workaround is to open the database handles and keep them open for
>     the duration of the program, which is actually the more common thing
>     to do anyway.  If we're not closing and opening all the time, the
>     error shouldn't get a chance to happen.
> 
>     The one exception is wallet.dat, which I still close after writing
>     is finished so I can flush the transaction logs into the dat file,
>     making the dat file standalone.  That way if someone does a backup
>     while Bitcoin is running, they'll get a wallet.dat that is valid by
>     itself without the database transaction logs.
> 
>     This is a restructuring of the database handling, so we might find
>     some new deadlocks.  Usually if it deadlocks, either the UI will
>     stop repainting, or it'll stop using CPU even though it still says
>     Generating.
> 
>