이메일 #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:
만약을 대비해 실행하기 전에 데이터 디렉터리를 백업하세요.
Db::open/Db::close "Bad file descriptor" 예외에 대한 임시 대응입니다. 초기 블록 다운로드가 더 빨라질 수도 있습니다. 임시 대응 방법은 데이터베이스 핸들을 열어 프로그램이 실행되는 동안 계속 열어 두는 것으로, 사실 어차피 이렇게 하는 쪽이 더 흔합니다. 이렇게 계속 닫았다 열었다 하지 않으면 오류가 끼어들 틈이 없을 것입니다.
유일한 예외는 wallet.dat입니다. 쓰기가 끝난 뒤에는 여전히 닫아서 트랜잭션 로그를 dat 파일에 비워 넣고, dat 파일을 단독으로 쓸 수 있게 만듭니다. 그렇게 하면 누군가 비트코인이 실행되는 중에 백업을 하더라도 데이터베이스 트랜잭션 로그 없이 그 자체로 유효한 wallet.dat을 얻을 수 있습니다.
이번 변경은 데이터베이스 처리를 뜯어고친 것이어서 새로운 교착 상태가 몇 개 나올 수도 있습니다. 보통 교착 상태에 걸리면 UI가 다시 그려지지 않거나, 여전히 Generating이라고 표시되는데도 CPU를 쓰지 않게 됩니다.
영어 원문
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] 님이 썼습니다:
Drupal의 포럼 기능은 어떻습니까? 주소는 다음과 같습니다: https://174.143.149.98/drupal/. CMS 전반이 TikiWiki보다 더 좋아 보이고 더 단순합니다. 포럼이 충분히 좋지 않다면, 물론 phpBB 같은 전용 포럼 소프트웨어를 쓸 수 있습니다.
zetaboards에 대해 제가 떠올린 또 다른 문제가 있습니다. 대부분의 무료 포럼 사이트는 옮기려고 할 때 사용자 계정 데이터베이스를 내보내 주지 않습니다. 다른 소프트웨어 프로젝트가 무료 포럼을 쓰는 경우를 본 기억이 없는데, 나중에야 알게 될 만한 이유가 있을 거라고 짐작해야 합니다.
VPS에 phpBB3을 설치할 수 있다면 그쪽이 아마 더 나은 선택일 겁니다.
다른 포럼들에서 본 바로는, 대역폭 비용이 문제가 될 경우 상단의 작은 Google Adwords(텍스트 링크)만으로도 게임 같은 가치가 매우 낮은 트래픽에서도 대역폭 비용보다 더 많은 수익이 납니다. 이쪽은 보상을 많이 주는 gold merchant 키워드와 VPN 호스트를 겨냥한 훨씬 가치 높은 트래픽이 될 겁니다. 결국에는 어느 무료 사이트에 넘기기 아까운 소중한 수익원이 될 수도 있습니다.
버전 0.2의 기능 중 일부를 포럼에 미리 알리고 기대감을 모아 보려고 합니다. 다른 사람이 글을 거의 올리지 않더라도, 글 대부분이 작성자가 최신 변경 사항을 알리는 내용인 프로젝트 포럼을 본 적이 있습니다. 사용자는 진행 중인 작업을 보고, 개선되고 지원되고 있으며 방치된 소프트웨어가 아니라는 점을 알 수 있습니다. 그런 경우에는 블로그와 조금 비슷하지만, 사용자가 검색 가능한 FAQ로 쓰기 쉽고 더 잘 정리되어 있습니다. 소프트웨어 질문을 구글에서 검색할 때마다 결과 대부분은 포럼 글입니다.
영어 원문
[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
한글 번역
phpBB3와 Simple Machines Forum을 둘 다 설치해 봤습니다. 둘 다 오픈소스 포럼 중에서는 시장을 이끄는 편입니다. 첫인상으로는 SMF의 인터페이스가 더 좋아 보이고, 특히 관리자 패널이 그렇습니다. 어떻게 생각하십니까, SMF와 phpBB3 중 어느 쪽으로 할까요?
영어 원문
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
한글 번역
혹시 여전히 쓸모가 있을까 싶어 로그를 보냅니다.
오류가 난 파일이 무엇인지에 따라 쓸 수 있는 임시 대응책 아이디어가 있습니다. db.log에 오류가 몇 개 쌓였다면 보내 주시겠습니까? (꽤 단순하고 볼품없더라도요) 나와 있는 파일이 항상 blkindex.dat입니까, 아니면 addr.dat나 wallet.dat도 포함됩니까?
영어 원문
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]>
한글 번역
드디어 쉬운 문제가 하나 나왔네요. 초기 다운로드 같은 긴 작업에서는 그렇게 될 수 있는 경로가 보입니다. TryLock 버그는 db 쪽 문제와는 관련이 없습니다. 수정 내용은 test8에 들어갈 겁니다.
32비트 Linux에서 멈추지 않는 요청을 계속 퍼부어서 db::open/close 예외를 지금까지 3번 재현했습니다. wallet.dat 데이터베이스를 비우려고 주기적으로 닫기만 해도 db::close 예외가 생기는 것 같습니다. Linux에서는 지갑 flush 기능을 끄겠습니다. Linux에서는 종료할 준비가 될 때까지 데이터베이스 핸들을 절대 닫지 않을 겁니다. 지금까지는 이 기능을 끄고 나서는 예외가 없습니다.
질서 정연한 초기 블록 다운로드도 구현하고 있습니다. 모든 블록을 한 번에 무턱대고 요청하는 대신, 한 번에 500개씩 묶음으로 요청하게 됩니다. 이렇게 하면 재시도 제한 시간이 지나기 전에 블록을 받게 되니, 실제로 블록을 받지 못하거나 너무 느린 경우가 아니면 다른 노드에 다시 요청하지 않게 됩니다. 이 변경은 요청을 받는 쪽에 있어서, 새 버전이 설치된 노드에서 초기 블록 다운로드를 받을 때가 되어야 이 기능이 눈에 보이게 됩니다.
test8을 보내기 전에 이 부분을 좀 더 테스트해 보겠습니다.
Liberty Standard님이 쓰셨습니다:
test7으로 새 데이터 디렉터리에서 시작했습니다. 블록이 훨씬 빨리 내려받기 시작했습니다. 예전 Linux 빌드에서는 몇 분 걸리던 것이 15초 정도밖에 안 걸렸습니다. 블록을 내려받는 중에 한 번 충돌했는데, 터미널에 다음과 같은 메시지가 나왔습니다.
../include/wx/thrimpl.cpp(50): assert "m_internal" failed in TryLock(): wxMutex::TryLock(): not initialized [in child thread] Trace/breakpoint trap
로그 파일을 첨부했는데, 비트코인을 다시 시작하기 전에 백업하는 것을 잊어서 로그 파일의 어느 지점에서 충돌이 일어났는지 잘 모르겠습니다.
다행히 아직 세그멘테이션 오류는 만나지 않았습니다. 이전 빌드들에서는 세그멘테이션 오류 빈도가 꽤 들쭉날쭉했으니, 계속 실행해 보면서 문제가 생기면 알려드리겠습니다.
2009년 11월 17일 화요일 오전 5시 41분에 Satoshi Nakamoto <[email protected] <mailto:satoshin@gmx.com>>님이 쓰셨습니다:
test 7:
만약을 대비해 실행하기 전에 데이터 디렉터리를 백업하세요.
Db::open/Db::close "Bad file descriptor" 예외에 대한 임시 조치입니다. 초기 블록 다운로드가 더 빨라질 수도 있습니다. 임시 조치는 데이터베이스 핸들을 열어 프로그램이 실행되는 동안 계속 열어 두는 것으로, 어차피 더 흔한 방식이기도 합니다. 계속 닫고 열지 않으면 오류가 일어날 틈이 없을 겁니다.
한 가지 예외는 wallet.dat인데, 쓰기가 끝난 뒤에는 여전히 닫아서 트랜잭션 로그를 dat 파일로 비워 넣어 dat 파일을 단독으로 쓸 수 있게 합니다. 이렇게 해두면 누군가 비트코인이 실행되는 중에 백업을 해도 데이터베이스 트랜잭션 로그 없이도 단독으로 유효한 wallet.dat를 얻게 됩니다.
데이터베이스 처리를 다시 짜는 것이라 새로운 교착 상태가 몇 개 나올 수도 있습니다. 보통 교착 상태에 걸리면 UI가 다시 그려지지 않거나, 아직 Generating이라고 표시되는데도 CPU를 쓰지 않게 됩니다.
영어 원문
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.
>
>