landiskにsshdとNFSを入れてみた。さすがにSambaよりNFSのほうがスループットが出る。ただ2GB越えできなくなっちゃうのはなにゆえ…？ sshで入ってddとかでファイルを書くと25MB/s程度。しかしそこからも2GB越えができない。2147483647=0x7fffffffでFile size limit exceededだと言われる。しかし不思議なのはSambaからは2GB越えられること。lsで見ても「Value too large for defined data type」なんて言われるけど、できてるものはできてる。カーネルやファイルシステム(ext2だった)は対応してて(そもそもけっこう前から対応してるはずだ)、lsとかddのコマンド類が対応してないというのは、コンパイル状況によっては充分ありうるので、そういうことなんだろうと思う。それにしてもNFSはv3から2GB越えられるようになってるはずだから、v3でマウントして2GB越えられないのは何かがおかしいのではないかと思うけど…まさかv2でマウントしてたりして。 というわけでNFSのほうがスループット出るしシンボリックリンクも使えるんだけどSambaのほうが実用的、ということになってしまった。アップデート(1.42)が出ていたので、入れてみたけど変わらなかったよ。しばらくはNFSとSambaを併用かなぁ。 (追記) 2004-10-26 20:17 landisk、NFSv2しか生きてないな…。残念。

ふと気がつくと、Fedora Core 1がhttp://fedoralegacy.org/(fedoralegacy.org)に移っていた。yumの見る先を変えなければ。しかし、もうレガシーか。 RedHat8.0はLegacyですらサポート終了。普段の環境がRH8ベースで、サーバがFC1だから、私はもう古いタイプの人間です。

gcc hogehoge.c -o hogehoge.c

あ、あ、あれぇ！？ というわけで、LVMのsnapshotがこのような事故を防げそうだということで、昨晩試してみた。とりあえず入れたのはFedora Core 3 test2。普通に入れると/とswapがLVMになるやつ。というかdevelopmentをrsyncで取ってきてCD-Rからのブートのときにlinux askmethodでそっちから入れて、「更新はありません」状態でインストールされたので昨日あたりのdevelopmentと言ったほうがいいのかな。 インストーラでボリュームを切るときに、まずLVMのボリュームグループを定義して、孤独な論理ボリュームを作りつつ1GBくらい残しておく。手動でやってsnapshot領域を残しとかないと意味がない。面倒だな。自動かつ最後にチェックするようにしといて、最後のチェックのところで縮めるほうがいいのかもしれない。一度自動で残りのない状態でインストールしてしまったので、swapを犠牲にしながらsnapshotを試してたんだけど、やばそうだった(笑)。resize2fsはマウントされてると駄目っぽいしね。 で、おもむろにlvcreate -s -L 512m -n snap2004100600 /dev/VolGroup00/LogVol00みたいにしてスナップショットを作る。オリジナルのボリュームに変更があるたびに、snapshotボリュームは8KB単位で消費されていく。lvdisplayでどのくらい消費してしまったかがわかる。消費し尽くすとsnapshotは機能しないのだろうと思うがまだそこまでは試していない。vgdisplayでボリュームグループにどのくらい空きがあるのかがわかるので、足りなくなったらlvremoveで消していけばいい。ということになっている。snapshotはリブートしても有効で、普通にマウントできるし、なかなか便利に使えそうだ。 しかし…lvremove固まるよ(笑)。普通にswapを消すとかはswapoff -aしてlvremoveしても問題なかったのだが、snapshotボリュームの削除がなぜかうまくいかなかった。ディスクはけっこう回っていたから、もしかして私が短気なだけで時間が経てば終わるのかもしれないが。最初にswapのsnapshotを作ってしまった(笑)のが悪かったのかなぁ。 使うsnapshotの容量はちょっと予測しづらいけど、/丸ごとのsnapshotを512MBで取ってしばらく作業していたらすぐに20%近く消費してしまったので、そのへんはいろいろ考えていく必要がある。とりあえず考えているのは、/varを別ボリュームに押しやり、noatimeでマウントすればその他丸ごとでも512MBあれば1〜2日は持つんじゃないかな、ということくらい。 だから、インストールのときに6GBくらい余らしといて、snapshotを作りつつ古いsnapshotをローテートっぽく消していく、といったスクリプトを2時間に1回くらいcronで回す運用にすればいいのではないかと思う。ノートPCでサスペンドすることを考えると12x512MBでも2時間単位で2〜3日前までは戻れる計算になる。snapshotが512MBでは足りなかったり余る傾向が強ければまたLVMの構成を変更すればいいだけだし。しかしこれやるとwrite系の処理が12倍遅くなるのかなぁ。最悪ケースで古い8KBブロックを12回コピーしてから処理するわけだからねぇ。複数のsnapshotをうまく扱ってくれるのかというのも試していないし、そのへんも検証が必要だ。 残る課題にはlvremoveが固まる問題もあって、これらが解決したらメインの環境をLVMに移行してsnapshot生活を満喫しようと思う。 最近はけっこう便利な世の中になってるのかなぁ。しかしぐぐって調べてても、なんでみんなこの機能をバックアップ中に状態をフリーズさせるために使うなんていうくだらない(失礼)用途で説明するんだろうか。そんなのもともと気休めだしさ。だってアプリ側でatomicな処理だと思っている最中にsnapshotを作ってしまったら、どちらにしろバックアップは中途半端な状態になる。テープ等へのバックアップとsnapshot作成で時間の長さは違うけど、どちらにしてもゼロにはならない。ボリュームのバックアップにはもともと厳密さは求められていない*はず*。DBとかのバックアップにはDBMS側がバックアップの手段を用意しているので、そっちを使うほうがいいよねぇ。 (追記) 2004-10-06 22:51 多重にsnapshotをとっておくのは問題なさそうだった。性能は、別として。あと、lvremoveが変なんじゃなくて、全体的に不安定になっていたようだ。あんまり変なことしないほうがいいのかな。

yumのリポジトリを作るときは、以前はyum-archでheader.infoとheader/*を作るだけでよかったのが、createrepoでrepodata/*を作る必要があるようになった。なんだかなぁ。 たぶん、rpm本体よりはheaderのほうが小さかったのでそうやっていたけど、それでも大きいということでrepodata/*の単一ファイルにまとめるようにしたのだろうけど、repodataがないならheaderだけで処理するとか、そのくらいはクライアント側でやってくれても良さそうな気がするよ。

玄人はPostscriptを手で書くらしいですが、我々素人はもう少し簡単な方法を使う必要があると私は考えます。というわけで、半分オススメの方法。

1. TkのCanvasに絵を書く
2. Postscriptに出力する

例えばPythonのTkinterだと、次のような感じかな。メソッド名は補完が利くし、いざとなったらhelp(Tkinter.Canvas)でヘルプが見えます。

>>> import Tkinter
>>> c=Tkinter.Canvas(bg="white")
>>> c.pack()
>>> c.create_line(0,0,100,100,0,100,fill="blue",width=10,arrow="last")
1
>>> c.create_text(200,200,text="text!")
2
>>> c.postscript(file="outfile.ps")
''

Canvas.postscript()は引数なしだとPSの内容が文字列として返されます。ただし日本語のtextは画面上は見えるけど、PSにすると化けるようです(ダメじゃん)。 座標を手動で指定するのはいいけど、どこがどこだかわかんない！ という方は、

>>> def print_event(ev): print "x,y=",ev.x,ev.y
...
>>> c.master.bind("", print_event)

なんていうふうにしとけば右クリックでその位置の座標がわかります。

昨日のMHTMLの話の続きで、要するにページを保存するときに、関連する複数のファイルを保存したい＆URLをメタデータとして持っておきたいということだと思った。 これだけだったらzipやtarでファイル名が入る領域にURLの文字列を入れればいいだけだ。zipならアーカイブの中のファイル毎にコメントがつけられる領域があるから、コメントの部分にHTTPヘッダを生で保存すりゃいい。というわけでPythonで書いてみた。さすがにファイル名がURLだとWindowsでもLinuxでも開けない。展開すると…しないほうがいいって感じになる。普通のunzipとかじゃなくて、自分で書いたので展開していく必要がある。だってディレクトリのような名前でファイルのデータが入ってたりするし、Windowsの場合はそれ以前にファイル名が「http://」ではじまってしまうのを処理できてなかった。LinuxのunzipとかFileRollerの場合はhttp://はどうにか「http:」というディレクトリということで処理してくれたけど、やはりいまいちな感じ。 というわけでZipについて書いてみたり、mhtの猛烈に遅いCGIインタフェースを書いてみたのはいいんだけど(ちなみに昨日恥ずかしげもなく上げたmht.pyはforwardされる場合とかにけっこうバグります)、やっぱりMHTMLとZIPとtarと…というのをいろいろ組み合わせて、共通する部分は共通化したほうがいいと思うので、どういう構成にするかちょっと悩みはじめたよ。URLとリンク追跡とかの部分と、共通インタフェースを持ったアーカイブファイルの部分で階層に分けて、主をURLのほうに置けばいいのかなぁ。主をアーカイブのほうにしたほうがいいのかな。いや今回の主はURLのほうだ。 アーカイブの共通インタフェースはPythonの場合は標準ライブラリにZipFileとTarFileがあるから、ある程度は規定できる。あとは展開やCGIインタフェースのほうもURLが主のほうがやりやすいなぁ。mafみたいに特定の名前のファイルをRDFとして入れて使うか、先頭にあるファイルがメインのファイルだなんとな〜く思うか、というあたりも含めて。フォーマットの変換は簡単にできるようにしとかないと後で嫌になるだろうし。どうしようかな。この程度の話で眉間に皺を寄せて上げてFactoryMethodがどうの、とか言いだしそうな自分が恐いが。 なんでこんなこと言ってるかっていうと、やはり見たページは全部保管して後で処理したいなぁ、という思いが強くなってきたからだ。いわゆる個人用web.archive.org。「昔見たんだよなぁ」というページを全部保管してあって検索できるので至極便利、と言えるはずだ、よね。そのための要素がまだけっこう足りてないなぁ、と思っている。Webページ単位で、URLやヘッダ情報なんかも含めて元のファイルを完全に復元できる＆普通にローカルだけで見られるように加工して復元できる、という状態のアーカイブがあるのがいいと思う。コメントをつけられるとさらにいいかも。 「個人用web.archive.org」は意外と悲願だったりする。記憶領域があれば、「見たTV番組は全部保存しておく」とかもあってほしい。TV番組とかはどうせ見てない番組までオンデマンドでいつでもどこでも見られるようになる…はずだったんだけどな。世の中ってのはなかなか便利にならない。

こんなものはいかがか？ WindowsのIEではMHTMLという形式で、Webページ全体を保存することができる。MHTMLはメールの添付ファイルの形式をアーカイブ形式として使っている。なぜこのような形式を採用したのか理解しようとする必要はない(たぶんContent-Locationヘッダを使いたかっただけ でしょうけど)。 普通にIEで保存するとヘッダを書き換えられたりタグの大文字小文字をいじられたり空白が削られたり勝手にインデントがつけられたりする(f*ck!)が、まあHTMLの意味は変わらないので、表示だけなら再現できるようになっている。 そこで、mht.pyなんていうものを作ってみた。tarに似せたインタフェースでWebページを保存したり展開したりできる。Linux上のPython 2.2.3とかである程度は動作確認している。mozilla等のブラウザはmhtファイルに対応していないが、mht.pyを使えばmhtファイルをLinuxに持ってきて展開して読むことが可能になる。いずれはCGIとかのインタフェースをつけて、Webだけで完結させようかな。 イメージとしては、こんな感じ。

気になっている人は気になっていたかもしれませんが、という話。 iconvでUTF-8をEUC-JPに変換しようとしたとする。UTF-8の文字列の中に「−」(全角のマイナス/ハイフン)が含まれていると、不正な入力ということになってしまって、うまくいかないのね。 だからUTF-8なRSSをこのへんで表示させようとして、タイトルとかに「−」が含まれているとそこでタイトルが途切れてしまう。じゃあiconv使うなよって話なんだけど、mbstring入ってないし、そうもいかないでしょ。lv -Iutf8 -Oeucjpでも変換できずに「?」になる。mbstringの変換ではこれが大丈夫なのかどうかはよくわからない。 言いたいことは…これは私のせいじゃありません、ってことで(笑)。 でもなんでこんな状態のままでみんな使っているんだろうか。とりあえず避けるには、出力エンコーディングにUTF-8を使う。私は、避けませんけどね。 (追記) 2004-09-08 11:22 大丈夫な「−」もあります。UTF-8では「−」が複数あるようなんで。 (追記) 2004-09-09 10:57 URL入れてなかったな。このへん(miraclelinux.com)が参考になる。Samba 3.xでUnicodeに対応させたときの話。

*.aを*.soに変換する方法。

ld --whole-archive -shared -o libXXX.so libXXX.a

でどうにかなるらしい。ちょっとやってみたら大丈夫っぽかった。
＃ じゃあ今までつけてた-fPICって何だったんだろう… 逆に、*.soを*.aに変換するのに、

ar cru libXXX.a libXXX.so

ってのはアリなのかなぁ。こっちは試して(リンクしてみて)ないけど、アリであってほしい。 そうすると*.aと*.soの違いは何なのよって話になる。あー、フォーマットが違うのはわかってるよ。*.aは単に*.oのアーカイブだし、*.soは一種の実行ファイルみたいなもん(？)だけど、でも相互に変換できるものであるならば、*.soをstatic linkに使ったり、*.aをdynamic linkに使うことができても文句は言ってほしくなくて、ユーザにシームレスに見せろよって話になってしまう。

Firefoxの調子が悪い。Preferenceのウィンドウを出すと動かなくなる。いや〜ん。 (追記) 2004-08-25 12:06 なんか、本格的にヤバくなってきた。Segmentation Faultが出て落ちたり。ExtensionのPreferenceも出ないし。 なんでだよ！(先週土曜に小川直仁さんという人に何度か怒鳴ったセリフ)