12/30 (木)
実家に帰省中に風邪をひく
本日実家への帰省日。 事前に15日ぐらい前に予約をかけた時はすでに新幹線の指定席はとれなかったので、大混雑している東海道新幹線のぞみ号の自由席に搭乗する。 無論、立ち席。
しかし長時間揺れる車内に立っちぱなしなのは流石に膝に来る。新大阪で一度下車し、回復するまでプラットフォームの椅子に座って休憩。強い寒気に曝され続ける。
新大阪からは新岡山止まり「ひかりレールスター」の自由席に空き席を見つけて着座するが、体に悪寒が走り咳が出はじめる。
新岡山からいろいろ迷走しながら新山口、実家のある防府まで帰るが、完全に風邪をひいてしまったようだ。
12/26 (日)
[Linux] NILFS2 についての覚え書き
- Wikipedia | Log-structured file system
- NILFS - Continuous Snapshotting Filesystem for Linux
- IBM developerWorks Japan | 次世代 Linux ファイルシステム: NiLFS(2) と exofs
Linux kernel 2.6.30 に取り込まれたログ構造化ファイルシステム(log-structured file system)の一種 NILFS2 の覚え書きを書いておく。 あとで独立したページに移動するかも知れない。
ログ構造化ファイルシステムは 1. のリンクの先にあるように、ディスク上をサイクリックバッファのように書き込むファイルシステムである。 書き込まれたファイルはデータ部もメタデータ部も追記され、古いデータはディスクが一周してくるまでは破壊されずに残ることになる。
主に以下のような特徴を持っている。
- 過去のデータを全て持っているので、時系列に沿ったスナップショットが自動的に採っているのと同じこと。 Windows の Volume Shadow Copy によるスナップショットや Mac の Apple Time Machine のような自動バックアップとして使える。 NILFS2 の場合、理論上 5 秒単位で元に戻せる。 ただし ZFS や Btrfs のようなスナップショット後に各スナップショットに別々の書き込みを行なうことはできない。
- 過去のデータをディスクの容量が許す限り持っているので、ディスク書き込みの失敗に対する耐久性が高い。 ジャーナリングファイルシステムは、クリティカルなタイミングでディスクへの書き込みが失敗するとデータ内容が壊れるのを防げない。 ただしログファイルシステムであってもディスクの物理的な損傷を防げるわけではないので、データの安全性を考えると結局 RAID が必要になる。
- 複数のファイルへの書き込みをディスク上の連続したブロックに「ログ」として書き込むので、ランダム書き込み性能が非常に高い。 性能的にシーケンシャルライトとランダムライトはあまり変わらない。
- 常に新しい位置に書き込み、(スーパーブロック以外は)ディスク上の全ての部分をまんべんなく書き込むのでフラッシュメモリのような書き込み制限のあるディスクと相性がよい(?)。
- ディスクがいっぱいになるまで書き込んだら、古いログの中で生きているデータを残して他を捨てる「ガーベージコレクション」の処理が必要である。
NILFS2 の場合も、上記の特徴が当てはまる。
ファイルの書き込み
NILFS2 のディスクへの書き込みの最小単位は 1K or 2K or 4K バイトのブロックであり、常にブロックを意識した構成となっている。 ブロックサイズは mkfs 時に決定される。
NILFS2 は i-node のデータ配列を一つにまとめた ifile があり、この中に i-node の生のデータが入っている。 ifile 自身も NILFS2 が管理するファイルであり特別な i-node 番号 6 が割り振られている。
通常のファイルは構成ブロックを B-Tree 形式のブロックマップで管理しており、ifile の対応するエントリはブロックマップの頂点のブロックを指している。 下の図は、分かりやすさのためにブロックマップを構成する各ブロックが、下位のブロックを2エントリ分だけ指示できるように描いている。
今 i-node 番号 1000 のファイルが下図のように B01 〜 B15 で構成され、ifile のうち i-node 番号 1000 のエントリを含む部分が B16 のブロックで構成されていたとすると、ディスク上に B01〜B16 のログが作成される。
次に i-node 番号 1000 のファイルの 3 番目のブロックの内容を書き換えたとする。 これはディスクの B03 の位置に内容が保持されているが、ログ構造化ファイルは既存のブロックの内容を書き換えずに新しいブロック B17 を割り当てる。 すると連鎖的にブロックマップの内容が変わり、ブロックマップ自身も新しいブロックが割り当てられる。 最後に ifile が更新されて、この部分も新しいブロックとなる。
結果としてB17〜B21 のブロックが新たに割り当てられ、これがディスク上に新しいログとして書き出される。
実際には他にも付随的なデータ構造があるが、基本的にこんな感じ。
この例では一箇所だけ変更しているが、複数のファイルに対して書き込みがあった場合も一つのログまとまって書き出される。
ファイルの読み込み
基本的には最新の ifile はディスクの先頭部分とメモリ上に存在している。 ここから読みたいファイルの i-node 番号を特定し、その部分の i-node のエントリを読む(図では省略しているが ifile 自身にもブロックマップがある)。 i-node のエントリからブロックマップを辿り、そこからデータブロックを特定することでメモリの内容が読める。
NILFS2 (やログ構造化ファイルシステム)のファイルの読み込みは、(連続ブロックに割り当てられた書き込みと異なり)ディスク上のバラバラな位置に散らばったブロックを読むことになる。
ガーベージコレクション
ログ構造化ファイルシステムは、ファイルを削除した場合でもディスクを消費するので、いつかディスク使用量がいっぱいになる。 この時は、ディスク上で最古の位置にあるログからをガーベージコレクション(GC)を行なうことになる。
GCの対象となったログ(複数のログが含まれることもある)から、生きているブロックを抽出し、それをディスクの先頭の位置にコピーして新しいログをつくる。 ディスク上の古いログ位置は解放して、今後の書き込み用のフリー領域とする。
ただし GC によってブロックが移動をすると、移動したブロックを参照していたポインタがおかしくなる。 これを防ぐために NILFS2 は仮想ブロック番号(vblocknr)を導入し、データ部やブロックマップは仮想ブロック番号でブロック番号を記録するようにする。
仮想ブロック番号から物理ブロック番号へ変換する動的アドレス変換(Dynamic Address Transfer; DAT)のテーブルが別にあり、実際にディスクから読み出す場合は仮想ブロック→物理ブロックの変換を行なっている。 GC がブロックを移動した場合、この DAT テーブルを書き直して同じ仮想ブロック番号が移動した物理ブロックを追いかけられるようにしている。
12/24 (金)
武蔵中原の富士通工場のクリスマス
武蔵中原の富士通工場は今日は一般の人も入場可能のクリスマスイベントを実施していました。
例年のようにビルにお子様(?)が書いた絵を投射する他、工場内のイルミネーションや屋台が出ています。
 |
 |
 |
 |
 |
 |
12/22 (水)
[Food] 味噌好き！みそごろう＠武蔵小杉 (食べログ)
武蔵小杉のタワープレイスのもう少し奥にある「みそごろう」のラーメンを食べてみる。
麺は触感が蕎麦で味がうどんという感じ。 つけ麺にするとよい感じなんだろう。 つけ麺を食べるべきだった。
 店構え |
 味噌ラーメン |
 麺は太い |
12/18 (土)
[Movie] TRON:LEGACY (公式)
川崎チネッチタで「TRON：LEGACY」の吹き替え版を観てきた。 3D 映画を見るのは去年に暮に観たアバター以来。 Alice in Wonderlandは 2D で観たからね。 3D の方式はチネチッタなので XpanD 方式。
発券場がガラガラで嫌な予感がしたのだが、公開二日目だというのに客席が半分も埋っていない。 人気ないのかしら？ まあストーリーはあってないようなものだが、ギミックを楽しむ映画だからね。
気づいた点だが、
- ゲームセンターの地下でグリッドに繋がる前に操作する端末に SolarisOS の文字が見えた。
- スタッフロールにバンダイナムコがクレジットされている。
- 作中の現実世界(2009年)の入力インターフェイスは、タッチパネル上に仮想キーボードを出す東芝のlibretto W110のような仕組みになっている(1989年に失踪した父親の残したコンピュータもだが)。叩いても押し返すような触覚がたらかないキー入力というは辛すぎないか？
- アイソーの設定やトロンがクルーを裏切った理由はよく分からん。
3D の効果だが、シーンによってはアバターよりもさらに立体的に見えた気がする。 映画業界が 3D 化のコツを掴んできたのか、見ている私が段々 3D に慣れてきたからなのかは分からない。 あるいは Avatar は字幕で観たのに対して、TRON:LEGACY は吹き替えで観たという違いも効いているのかもしれない。 字幕を眼で追ってしまうと映像への注意が散漫になって立体視の効果が減るように思える。
チネチッタのイルミネーション
クリスマスが近いのかチネチッタの広場もイルミネーションが飾られている。
 |
 |
シャープの GALAPAGOS と SONY Reader
昨日の横浜のヨドバシカメラで SHARP の GALAPAGOS と SONY Reader の展示を見てきた。 どちらも人だかりができていた。
SONY Reader の E-INK 方式の表示はやはり文字が見易い。 A4の論文を入れて読むには小さいが、新書や文庫本の類はこういうデバイスで読むのが一番読みやすかろう。 問題は電子書籍の市場が広がらないことだよなぁ。
12/13 (月)
[Unix] execve 実行時に自動的にファイルをクローズさせる
POSIX の exec 系関数を実行した場合、 元のプロセスで開いていたファイルのディスクリプタは exec 後に残ってしまう。
これを防ぐには open の flags に O_CLOEXEC を指定するか、
open 後に fcntl で file descriptor flags に FD_CLOEXEC を追加してやればよい。
int fd = open(file_name, O_RDONLY | O_CLOEXEC);
int flags;
if ((flags = fcntl(fd, F_GETFD)) == -1) {
/* error */
}
if (fcntl(fd, F_SETFD, flags | FD_CLOEXEC) == -1) {
/* error */
}
Subversion は export 時に O_CLOEXEC と FD_CLOEXEC の両方を指定している。
どちらか片方だけでよいと思うが、理由はよく分からない。
12/8 (水)
長年の疑問が氷解
鄭和(1371年-1434年)は15世紀の初めに永楽帝に使えた宦官で武将という人物。 2万7千名の大艦隊を率いて南海を遠征し、アラビア半島・アフリカにまで到達した。
人数だけでなく船のサイズも大きく、遠征に使われた宝船と呼ばれた呼ばれる船は大きいものには150メートルに達し排水量で3,000〜8,000トンはあったというわれる。 大航海時代の中で最大級のキャラック船が全長30〜60メートルで排水量が1,500トン程度というので相当に大きい。
ところで鄭和が南海を大遠征した目的は、「永楽帝が鄭和に行方不明の建文帝を探させた」という説がある。 永楽帝は靖難の変の際に建文帝に反乱をおこして帝位を簒奪しているのだが、建文帝は行方不明になっており死亡が確認されていない。 永楽帝はその捜索のために鄭和を遠征に出したという。 私はこれを受験参考書で読んだ。
どうみても珍説だが、この説の真偽は？もし偽だとすると、誰が言い出したのか？がずっと気になっていた(「私の疑問」のページ)。 宮崎 正勝の「鄭和の南海大遠征―永楽帝の世界秩序再編」(中公新書)を読んでも、この説自体が紹介されていない。 説があるということ自身が与太ではないかと疑っていたのだが、はてなブックマークのtaninswさんに、以下のページを教えていただいた。
§３.鄭和の西洋下りの目的と永楽帝の対外政策
鄭和の西洋下りの目的については、昔から様々な説があるようだ。 俗説としては、西方の雄ティムール帝国の東征の動きを牽制するのに、その隣接諸国と軍事同盟を結ぶためであるとか、海上に残存する反明勢力を鄭和艦隊に組み込んで、倭寇などと結びついて反乱を起こすのを防ぐため、などがある。 しかし、どちらも妥当であるとは考えにくい。 「明史」では、その目的を、靖難の変(1399〜1402)で南京陥落の際、命を落としたはずの建文帝が実は異国の地に落ちのびたのではないかと永楽帝が疑って、これを探し出すということと、諸国に明帝国の威光を示すこと、としている。 しかし、生きているかどうかもわからない前皇帝を探すのに、これほどの大艦隊を組織する必要があるとは考えられないし、なぜこのときに明帝国の威光を示す必要があるのかはっきりしない。 この大事業がなされた目的を知るには元から明への王朝交代に伴う対外関係の変化に目を向ける必要がある。
東西の陸と海とのネットワークを掌握し、非常に盛んに貿易が行われた元代が、明の太祖洪武帝によって終わりを告げると、洪武帝は一転、海禁政策をとり、朝貢貿易以外、民間の自由貿易を厳しく取り締まった。 これに対し、永楽帝は積極的な対外政策をとり、側近である宦官を諸外国に派遣し、ヴェトナム征服や５回に及ぶモンゴル親征を行った。 こうした政策は永楽帝が元のような対外的に開かれた大帝国を理想としたからであるが、貿易に関しては、自由貿易は初代洪武帝の祖法に触れるため実施できなかった。 そこで、海禁政策で滞っていた輸入物資（特に香料や奢侈品）に対する国内需要の高まりに対応するためもあって、大明帝国の威光を示す使節としての役割と、朝貢貿易による恒常的な大規模貿易圏の確立という使命を担った大艦隊が組織され、その指揮官に鄭和が任命されることになるのである。
鄭和の西洋下り (下線は nminoru)
というわけで明帝国の正史「明史」に書かれているそうな。 この説は正統なのか orz
P.S.
taninsw さんからさらに以下の情報をいただいた。
taninsw 原文がありました。 http://j.mp/fxg3B5 明史304巻4段落目 「成祖疑惠帝亡海外，欲踪迹之,……」 (この部分は幸田露伴の運命にありました。 http://j.mp/bo3LNu) 成祖(永楽帝）、恵帝（建文帝）の海外に亡げたるを疑い > id:nminoru 2010/12/08
はてなブックマーク - 鄭和 - Wikipedia
12/5 (日)
[Food] エチオピア料理「クイーンシーバ」＠中目黒 (ぐるなび)
久しぶりの「エンゲル係数を高める会」の活動。 滝田さん、三浦くん、豊島くんで中目黒にあるエチオピア料理店「クイーン・シーバ」に食べに行きます。 このお店は前回2008年2月1日に行きました。
ここは東急東横線の中目黒駅から徒歩7分と割とわかり辛い位置にあります。 とはいえ最近は GPS 付きのスマートフォンが普及したので恐れるに足らじ。 私の携帯電話は mova ですが。
 お店は注意していないとうっかり通り過ぎる。 |
 看板 |
 お店は地下にあります。 |
おすすめセットメニュー(一人3,500円)を頼んで、 エチオピア煮込み料理を4種類をシェアして食べます。
以前も書きましたがエチオピアの主食はテフというイネ科の植物。 米の仲間ですね。 これを水で延ばして発酵させた後、薄く延ばして焼いたのがインジェラです。 これを煮込みシチューと一緒に食べるのが一般的だそうです。
テフは独特の酸っぱさがありますが、個人的には好みです。
 サモサ レンズ豆のエチオピア風春巻き |
 レタスとビーツのサラダ |
 チキンとヤギのカバブ |
 エチオピア風スクランブルエッグ、野菜マリネ |
 インジェラ(下の簀巻き状のパン) ダボ(上のパン風のもの) |
シチューは4種類を選択。 チキン、ラム、レンズ豆、ビーフを辛口とマイルドを組み合わせて注文している。 |
 お店の人がシチュー2皿とインジェラとダボをサービスしてくれたよ!! |
|
お店の人がシチューを2皿サービスしてくれましたが、 なんと最初に注文したのとほぼ同量のインジェラとダボまで!!
 プチデザート |
撮影し忘れましたが、デザート以外にコーヒーが付きます。 当然エチオピアンコーヒー(?)。 でも私にはコーヒーの違いはよく分からない。
 おまけ：トイレの壁紙 |
12/2 (木)
実印作成
いろいろな理由で実印を作成した。 これから印鑑登録を行なう。
 |
ブレードサーバの再インストール
昨日壊れたブレードサーバに OS を再インストールする。
BX900 にささっているブレードサーバは BX920 S2 だが、 x86-64 版の Fedora 13 が RAID カードを認識できず、 やむをえず Fedora 12 をインストールする。