2010-07-05 :-)
_ 朝ッ
0520 起床
_ 君のあんみら服姿が見たい！
だそうな
_ [RAID][RAIDframe][NeBSD][翻訳]NetBSD Blog - Google Summer of Code: Improving RAIDframe parity handling 翻訳
Google Summer of Code: RAIDframe パリティハンドリングの改善
June 21, 2009 posted by Jed Davis
Summary
概要
A NetBSD system, in order to tolerate disk failures, can use the software RAID driver raid(4). Currently, if that system is shut down uncleanly (e.g., loses power or crashes), then when it comes back up it will have to check the entire RAID set's redundancy information. This process can take many hours, during which it imposes a substantial load on the system. It is also a distinct disadvantage to using NetBSD in server applications, and the inclusion of a journaling filesystem in NetBSD 5 makes it all the more prominent.
NetBSD システムは、ソフトウェア RAID ドライバ raid(4) を使うと、たまにディスク不良を見逃す。いまのところ、きれいにシャットダウンしなかった場合は( 例えば、電源断したとかクラッシュなど )、バックアップが使われ、そのバックアップ全体( 冗長性の部分も含めて )に対してチェックが走る。この処理はものすごく時間がかかり、その間システムにはものすごく負荷がかかる。これは NetBSD をサーバーとして使用するうえで不利にもなるし、NetBSD 5 で採用されたジャーナルファイルシステムを使った場合はもっと顕著になる。
The goal of my Summer of Code project is to shorten that check from hours to minutes.
私の Summer of Code project の目標は、数時間かかるこのチェック時間を数分に短縮することだ。
More Detail
さらに詳細
The problem is due to a fundamental limitation of RAID: if the system is abruptly halted in the middle of writing to several independent disks, there is no way to tell afterwards which of those write operations were actually performed short of reading the actual data involved. This is especially problematic for RAID-5 and similar, where a mismatch between data and parity will result in garbling part of that data when (not if) it has to be reconstructed after a disk failure.
この問題は RAID が持つ根本的な制限による: 独立した複数のディスクへの書き込み途中でシステムが突然死した場合、書き込み処理が実際には完了していた short of な読み込み中の実データが巻き添えを食らうので、それ以降利用する方法は無い( 訳: ??????????? )。これはとくに RAID-5 やそれと似た構成で問題になる。データとパリティの間に差異があると、ディスク不良が発生したあとに再構築されたデータについては間違いなくデータが化ける。
The solution taken in the RAIDframe codebase used by NetBSD is simple: while a RAID device is configured and in use, the entire thing is marked as needing a parity rewrite — even though only a small part, or perhaps none at all, has write operations in progress at any given time.
NetBSD では RAIDframe をもとにすると解決方法は簡単だ: RAID デバイスを設定してる間か使用している間は、RAID 全体をパリティ再書き込み要求させるようにマークをつけておけばいい。まあ全体に対してではなく一部に対してのみだけど、それでも書き込み処理はその特定の時間のうちは処理が進む。( 訳: ???????? )
Thus, my fix is to record a better approximation of what parts of the RAID are being written to at any given time. Except that now the RAID driver has to update that record as writes are done, rather than just once on boot and once at shutdown, and if this approximation is too fine-grained then that will noticeably reduce performance — all of the time, not just after unplanned reboots.
( 訳: 力尽きた )
Status
状態
At the time of this writing, I have a prototype implementation of just such a parity map; it's not fit for general consumption at this point, but the basics are working. Next up is more testing and performance evaluation, to refine the parity map algorithm. Eventually there will need to be an interface for the system administrator to configure this feature, and the code will need to correctly handle a RAID set being moved between kernels with and without parity map support, but these should be relatively straightforward and are scheduled for later in the summer.
これを書いているいまは、パリティマップ実装のプロトタイプが出来上がっている。ただ、いまの時点では一般的な使用( 訳: general consumption ???? )には適さないんだけど、基本的な部分は動いている。次に、パリティマップアルゴリズムを改善するために、もっとテストし、パフォーマンスを評価する。最終的に、管理者がこの機能を設定するためのインターフェースも必要になるだろうし、パリティマップサポート済みカーネルと未サポートのカーネル間で RAID セットを移動したとしてもハンドルを正確に収集できるようにしたいのだけど、比較的単純に実装しても、日程としては夏終盤になる。
Some additional minor improvements to the RAID system are also planned, time permitting, pertaining in particular to the handling of spare disks and reconstruction after a disk failure. In any case, by the end of the summer, a notable weakness of NetBSD will have been corrected.
あといくつか RAID システムの多少の改善も計画していて、時間があれば、とくに予備のディスクのハンドルに関連することと、ディスクが死んだあとの再構築について実装したい。ともあれ、夏の終わりには、欠陥がないように NetBSD が修正されるだろう。
_ AsiaBSDCon
hrs へメール投げてみた。
