![[Donate to CCjp]](images/cc_donation.png)
2000|12|
初代渡辺フォントの製作者とは話し合いができておりませんが、フォントデータを見る限り、日立−タイプバンクの３２ドット明朝体ウェイト３そのものと判断しております。このフォントは、我々が商品として現在も販売しているものであり、使用許諾の対象外です。申し訳ありませんが、お申し出に沿いかねます。
と言うことは機械変換したTTF版も駄目なのかな。 しかしどちらにせよ DFSG non-free か……
上の tvtime の記事からリンクされていたもの。 作者がパッケージ化かから学んだ教訓とのこと。
まず最初に "Packager-developer communication is poor" って言われてるね。 自分もちゃんとしないとなぁ……
信頼性が高いとされるジャーナリングファイルシステムだが、ジャーナルによって何が保護されるのかを理解していないと、とんでもない落とし穴にはまってしまう。今回は、ジャーナリングファイルシステムの総論とそのほかの各種技術について解説する。（編集局）
@IT. 検索しやすいようにとりあえずメモしておこう。
長い利用実績を誇るext2の互換ファイルシステムext3。このファイルシステムにはどのような特徴があるのか？ そしてどのようにジャーナリングを実現しているのか？ 今回はext3について解説する。（編集局）
次の記事。
うーん Journaling Block Device (JBD) には触れられていないか……。 前にちょっと追い掛けて、果たして正しいのか確信する前にやめてしまったのだけど。
ともあれ前の調べたことメモしておこう。 大嘘を書いている可能性もあるので注意。
記事中に
ext3はジャーナルログの保存のために、デフォルトでルートパーティションに.journalというデータベースを保有している。後で紹介するが、複数のファイルシステムでこのデータベースを共有することもできる。
とあるが、ルートパーティションではなくてそのファイルシステムのルートの書き違いだろう。 また、共有は……本当に出来るのかな？ これについては後で。
まず最初に、/.journal ファイルが使われていたのは既に過去の話だ。 e2fsprogs の RELESE-NOTES には、
E2fsck will automatically relocate the ext3 journal from a visible file (i.e., /.journal) to an hidden inode if the filesystem has been opened read/write. This allows the users to add a journal while the filesystem is mounted, but the next time the system is rebooted, the journal file will disappear. This avoids problems with backups, stupid operators with superuser bits, etc.
[E2fsprogs 1.26 (February 3, 2002) - RELEASE-NOTESより引用]
とある。
元々 ext3 のジャーナル機構は Journaling Block Device (JBD) と言うシステムを 利用している。JBD はその説明に
The Journaling Block Device layer (JBD) isn't ext3 specific. It was design to add journaling capabilities on a block device. The ext3 filesystem code will inform the JBD of modifications it is performing (Call a transaction). the journal handle the transactions start and stop, and in case of crash, the journal can replayed the transactions to put the partition on a consistant state fastly.
JBD can handle external journal on a block device.
[Journaling Block Device layerより引用]
とあるとおり、ブロックデバイス上にジャーナル情報を保存する汎用APIらしい。 ジャーナルログの保存場所は ext3 ファイルシステムを作ったパーティションや 論理ボリューム内だけではなく、外部のブロックデバイスにも指定できる。
ディフォルトの外部デバイスを使わない方法では、ext3 ファイルシステム内に 予約された（使用中マークをつけた）i-nodeを確保し、ファイルシステムのマウント時に、 その i-node が割り当てたれた実際のブロックデバイス上の位置を割り出して ジャーナル領域として使う。
この予約された i-node は最初 /.journal と言うファイルに結びつけられていた （これは古い fsck によって削除されるのを避ける為ではないかと思うのだけどどうなんだろう？）。 が、ともあれ最近では RELEASE-NOTES にある通りファイル名へのリンクは切られている。
だからファイルシステムレベルのキャッシュとか遅延書き込みとかが効いて まともにて動かない──と言う話があったけど、 これは /.journal ファイルが存在していた事による誤解じゃないかと。
IBM developerWorks の アドバンスト・ファイルシステム・インプリメンター・ガイド: 第7回 でもほんのちょっとだけ出てきます。
２ページ目に
■外部ジャーナルファイルの指定
別のデバイスのジャーナルファイルを利用する場合は、初めに外部デバイス側のジャーナルファイルを作成し、それを利用するデバイスを指定する。
[ext3関連コマンドより引用]
と書いてあるので、ext3 ファイルシステムが出来、その上ににジャーナル 「ファイル」が出来るのかと思ったが、そうではない。
mke2fs -O journal_dev /dev/hda5
とかやると /dev/hda5 全体がジャーナルログのために確保される。 普通に ext{2,3} のスーパーブロックは作られるみたいで、 dumpe2fs で情報を取ることは出来る。 見てみると分かるが Free blocks: 0, Free inodes: 0 になっている。 （ただし普通にファイルシステムを作るのと違って、スーパーブロックの バックアップは作られない。先頭のみ）
そして、
mke2fs -J device=/dev/hda5 /dev/hda4
これをやると /dev/hda4 にファイルシステムが作られ、 ジャーナルデバイスの /dev/hda5 側にそこをジャーナルログとして使っている ext3 ファイルシステムの UUID が書き込まれる。
確かに複数のファイルシステムを一つの journal device に結びつける 事は出来るみたいで、
mke2fs -O journal_dev /dev/sdb3 mke2fs -J device=/dev/sdb3 /dev/sdb1 mke2fs -J device=/dev/sdb3 /dev/sdb2
と実行すると
[root@localhost root]# dumpe2fs /dev/sdb3 | tail -3
dumpe2fs 1.27 (8-Mar-2002)
Journal number of users: 2
Journal users: 9374d934-765b-4c9f-99fa-2e11b4c97d04
f1aaad3c-af37-415c-9e59-ff656712d4a9
と２カ所から使われていることになっている。
でも、
[root@localhost root]# mount -t ext3 /dev/sdb1 /mnt/sdb1
EXT3-fs: External journal has more than one user (unsupported) - 2
mount: wrong fs type, bad option, bad superblock on /dev/sdb1,
or too many mounted file systems
こんなエラーになってしまってマウントできない。 もしかして kernel が古い(2.4.18) からなのかな？
確かに互換性がありますが、いきなり ext2 でマウントし直したりせずに、
tune2fs -O ^has_journal /dev/hdaX
で journal があるという情報を消してから
fsck.ext2 -f /dev/hdaX
と一応 fsck をかけた方が良いようです。
もし、journal 情報を消さずに
ってやるとどうなるんでしょう。ちゃんとやってくれるのかな
なんだか日記に書く量ではなくなってきました……
その資料を読む限り、基本的に "Journal ファイル" が ext2 上にあるから、まともにジャーナルログが記録されない、と言う話だと思うのですが。
でも、コードを適当に読んでみた限りでは、どうもジャーナルログを書くために ext2 を経由していると思えないのです。JBD の初期化をしている fs/jbd/journal.c を簡単に追い掛けて行くと
と言う感じに読めました。 ……ただ、ext3 の bmap が何か特殊なことをやっているようなんですが、 そこら辺まではちゃんと見れていません。それに私にまともな知識がないので、 思い切り外している可能性は結構あります。どうなんでしょう？
コードを整理しつつごりごり。 とりあえずローカルファイルが扱えるようになったはず。……はず。
うーん。先が長い。 1.8 のみと言うことで避けていたけど、やっぱり open-uri 使うかな……
本格的に動かないらしい……。
I run/use Ruby 1.8 on PPC and got problems with running virtually every
Ruby script (and not only 'include' is the problem). Some very simple
examples:
---snip---
paul@power pts/0% ruby -e 'p a'
-e:1:in `method_missing': stack level too deep (SystemStackError)
from -e:1
paul@power pts/0% rubye -e 'require "yaml"; include YAML'
/usr/lib/ruby/1.8/date/format.rb:24: stack level too deep (SystemStackError)
from /usr/lib/ruby/1.8/date.rb:4:in `require'
from /usr/lib/ruby/1.8/date.rb:4
うー。間に合うかな。
本文書の目標は、認証に LDAP を利用する Apache + MySQL + PHP + WebDAV ベースのウェブアプリケーションサーバを構築することです。この文書は、LDAP トランザクションの暗号化に関する詳細な解説も行います。
[はじめにより引用]
JavaApplet みたいな物。.NET Framework ってこういう機能もあるのか……
「平均的なユーザー」とは一体全体どんなユーザーだろう……。 自分の論拠に合うような母集団を定義すれば何でも言えるよね。 もしかしたら、その平均的なユーザーはコピーの方法なんて知らないから、 プロテクトなんぞつけなくてもコピーされないんじゃいないか？
http/dir の読み込みが出来るように。
sugi@tempest:~% ruby -rvfs -e '
dir = "http://sugi.nemui.org/pub/ruby/vfs/"
Dir.open(dir) { |d|
d.each { |fname|
if Time.now - File.mtime(dir + fname) < 24 * 60 * 60
puts %["#{fname}" has been updated in 24 hours.]
end
}
}
'
"libvfs-ruby-0.0%2Ba5.tar.gz" has been updated in 24 hours.
アンテナとかで使えるかもしれない。
ディレクトリ一覧は WebDAV の拡張が使用可能ならそちらを使うようにする。 と言うわけで帰ってくるのは XML なのだけど。 REXML を使ってみたら激しく遅い……。ストリームモードでもかなり遅い。 仕方がないのでいい加減な正規表現でパースする事に。うーん……
TEXTAREA だけ全部文字化けして暫く書く気が失せる。
やっぱり tdiary-mode を使うべきなのか。とりあえず deb 化待ち。
面白そうではある。あとは使いやすければ良いけど……
書いていたのが消えたので適当に。
どうせあらゆる物の９割は屑なのだ。投げられるコメントが屑ばかりなのも不思議ではない。 肯定的なひとや考えが変わった人は静かに頷くだけで表に出てこないと考えるのは愚かか。 黙った方が楽なことは確かだけど。
でもkazu氏も「あれでそんなこと言ってる様じゃ甘い」と言うようなことを仰っていましたが。
良さそうだなと思っていたのだけど、リリース版はまだないのかぁ……
一部だけ抜き出しても分からない話なので引用はしないけど、ともあれ面白い。
ただ、その鬱屈した感情を「怒り」と呼ぶのはどうも抵抗がある。 ……かといって思い浮かばないのだけど。
及び「続・ファイルシステム」。
grub 周りとかとても参考になります。
Linux のファイルシステムは確かに今色々あって、どれも一長一短だと思うんですが。
Web 上のコメントは「このファイルシステムは全く使い物にならない」と言う様な 書き方が多すぎる気がする。何処に問題があるのかをある程度突きとめないと価値がない。
自分が酷いクラッシュに見舞われたからと言っても、そこで「*** はゴミだ」で 終わってしまったら他の人への資料にはならないわけで。 自分の経験なんてたかが知れてるし、「経験的に***はよく壊れます」というのも 統計的は意味がないし。どういう環境下でどういうことをしたら壊れたのかが分かれば 良いのだけど、なかなか難しいのが難点……。 結構色々壊しましたが、結局一つも資料になるレベルにない。嗚呼悔しい。
逆に、読む方も「何処が駄目なのか、どういう時に駄目なのか」と言うのをちゃんと 拾えるようにしないと。問題点を１つ指摘してるだけなのに「そうかだめなのか。ステ」 とか言って他に移行して、もっと厄介な問題にぶち当たるというのは悲しすぎる（正に私だ）。
本題。……と言っても情報ありませんが。
あるext3復旧レポート なんかを読むと、ますます強く感じることですが、 ext3は駄目です。遅いし、noflushdは効かなくなるし、ぶっ壊れることが非常に多いです。落ちてしまった時に、ジャーナリングに任せて復旧させると、かなりの確率で、余計に破壊されてしまうことがあるようです。じゃ、全然ジャーナリングの意味ないじゃん！自分はもう3、4回はやられました。 ext3使うぐらいなら、ext2使う方がよっぽどましです
[ファイルシステム - enbug diaryより引用]
経験的にも ext3 は落ちてから、ジャーナルログを使って復旧するときに壊れることしばし。 一度 data=journal モードに酷いバグがあって、ほぼ必ず壊されるときもありましたが、 それを除くとしてもたまに壊れた。何でなのやら。
とりあえず「ジャーナルログを記録するためにファイルシステムレイヤを経由するので、 遅延書き込みなどにより、ちゃんとログが記録されない」と言うわけでは ない 雰囲気なのだけどなぁ……。（この辺についてはとりあえず ext3とJBDにメモしておく。） もう少しちゃんと調べないとあってるのかどうかがかなり怪しいのですけど。
GET と POST 以外のリクエストを投げたりすると
sugi@tempest:~% echo "RAISE_ERROR / HTTP/1.0 Host: www.google.com " | nc www.google.com 80 <html><head><title>400 Bad Request</title>(後略)
とか全くヘッダーの付いていない応答が帰ってくる。参ったな。
同じく 家族揃ってでびるまん（誤認 なんです より。
CやC++である程度大きなプログラムを書く場合，最大の問題点はメモリ管理である...(略)...ところが，このメモリ管理をプログラマが全然面倒見なくてすむ画期的な方法がある．それがBoehm GCだ.
[はじめにより引用]
隠し/Undocumented 機能らしい。
これを使って多言語を同じファイルに突っ込んだり出来ないかと考えたけど、 難しそうだなぁ……
yendot 経由。
今更だけどとりあえずメモ。 まだちゃんと読んでない……
同じく Rubyにまつわるえとせとら日記 経由。
まいじゃー推進委員会！ 経由。
イラストと【LOVE！】。 どう考えてもやばかったミステリー文庫が更にやばくなりそうな雰囲気……
そもそも最初に「ミステリー」とかつけた時点で負けているのじゃないだろうか。
輸入盤だと随分安かったので2つ。北欧トラッドなのだけど、猛スピードで叩き付ける 様な歌い方がかなり独特。アップテンポな曲調にはかなりあって良い感じです。
amazonのレビューによればフィン語らしいです。どっちにしろ分からないんだけど。
stat も出来るようになったので。とりあえず beta1。
WebDAV サーバに置いてある zip アーカイブ中のファイルを直接 open("w") とかあほな事が出来ます。
しかし、最初に互換性の事を考えすぎて、そっちに引きずられてしまったのが問題だなぁ。 何とか巧くまとめる方向へ行かないと。
次に何をやろうか。sshfs 擬きとか妄想してみたが難しそうだ……
LC で話をしていただけるようです。
某S氏は申し込んで通ったそうですが、 一体何を話せば良いのかと今になって頭を抱えております。 ５分なんですが。ええ。
そう言えば、最初に設定してあった締め切り日を過ぎたら、 締め切りの記述だけ消して今でも募集していますね。 よっぽど人居ないのでしょうか。
これを出して良いのかわかりませんけど。
今でも辛うじて 妖精現実フェアリアルの 2002/9/3 付けの記事 (の一番下)にある zip アーカイブから読むことが出来ます。
もしも、 原発がどんなものか知ってほしい だけしか読んでいないならば、是非こちらも読んで下さい。 置かれていたサイトが消滅しているので、ここだけ抜き出してもニュアンスが 正確に伝わらないかもしれないのが残念ですが、ともあれ読んだ上で自分で考えましょう。 "Re: 原発がどんなものか知ってほしい" は faq10.html です。
ところで、「諸君、私は原発が好きだ」を保存しておかなかったのが悔やまれる……
Ethernet ケーブル経由で電源を供給する規格らしい。 既に製品出てる模様。
device なんてコマンドがあるとは知らなかった。
device (hd0) /dev/hda
等とするとそれ以降 /dev/hda が (hd0) として扱える。
これ、デバイスファイルだけではなく普通のファイルも渡すことが出来る。 フロッピーイメージがあったら、中に grub のファイル一式を置いておいて、
device (fd0) /home/sugi/works/boot.img root (fd0) setup (fd0)
とすればイメージに対して grub がインストールできる。 素晴らしい。
from /.j とりあえずメモ。
upstream じゃないけど、日本語の対応もしているのか。
データが統計上有意かどうか判別する方法。
やすいしにおしえてもった。
セキュアなネットワークファイルシステム。 インターネット越しに使えて、しかも非常に簡単で使いやすい。
内部的には nfs を使っているのだけど、あの面倒くささとは大違いだ。 サーバが設定されているなら、クライアント側は sfsagent にキーを登録して /sfs/サーバFQDN に cd するだけでマウントできる。
何時か使いそうなのでメモ。
SCSI と RAID の面白そうなことが色々。 とりあえずメモ。