トップ 最新 追記

TPRG: 迷走メモ書き

[Donate to CCjp]
2000|12|
2001|01|02|03|04|05|06|07|08|09|10|11|12|
2002|01|02|03|04|05|06|07|08|09|10|11|12|
2003|02|03|04|05|06|07|08|09|10|11|12|
2004|01|02|03|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|07|08|11|12|
2009|01|02|
2010|04|06|09|

2003-10-01

_ [url] 東風フォントその後

同じ日付にまとめて書かれているので非常にありがたい。

_ [url] 日立プリンティングソリューションズからの返信

初代渡辺フォントの製作者とは話し合いができておりませんが、フォントデータを見る限り、日立−タイプバンクの32ドット明朝体ウェイト3そのものと判断しております。このフォントは、我々が商品として現在も販売しているものであり、使用許諾の対象外です。申し訳ありませんが、お申し出に沿いかねます。

と言うことは機械変換したTTF版も駄目なのかな。 しかしどちらにせよ DFSG non-free か……

_ [url] Lessons in Packaging Linux Applications

上の tvtime の記事からリンクされていたもの。 作者がパッケージ化かから学んだ教訓とのこと。

まず最初に "Packager-developer communication is poor" って言われてるね。 自分もちゃんとしないとなぁ……


2003-10-02

_ [Url] 第3回 ジャーナリングファイルシステムが保護する「情報」

信頼性が高いとされるジャーナリングファイルシステムだが、ジャーナルによって何が保護されるのかを理解していないと、とんでもない落とし穴にはまってしまう。今回は、ジャーナリングファイルシステムの総論とそのほかの各種技術について解説する。(編集局)

@IT. 検索しやすいようにとりあえずメモしておこう。

_ [url] 第4回 ext3とトランザクション処理

長い利用実績を誇るext2の互換ファイルシステムext3。このファイルシステムにはどのような特徴があるのか? そしてどのようにジャーナリングを実現しているのか? 今回はext3について解説する。(編集局)

次の記事。

JBD と /.journal

うーん 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 にある通りファイル名へのリンクは切られている。

ext3 はジャーナル情報をファイルシステムレイヤ経由で保存する?

だからファイルシステムレベルのキャッシュとか遅延書き込みとかが効いて まともにて動かない──と言う話があったけど、 これは /.journal ファイルが存在していた事による誤解じゃないかと。

JBD に関しては

IBM developerWorks の アドバンスト・ファイルシステム・インプリメンター・ガイド: 第7回 でもほんのちょっとだけ出てきます。

external journal の共有?

2ページ目に

■外部ジャーナルファイルの指定

別のデバイスのジャーナルファイルを利用する場合は、初めに外部デバイス側のジャーナルファイルを作成し、それを利用するデバイスを指定する。

[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

と2カ所から使われていることになっている。

でも、

[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) からなのかな?

ext3 から ext2 への変換

確かに互換性がありますが、いきなり ext2 でマウントし直したりせずに、

tune2fs -O ^has_journal /dev/hdaX

で journal があるという情報を消してから

fsck.ext2 -f /dev/hdaX

と一応 fsck をかけた方が良いようです。

もし、journal 情報を消さずに

  • mount -t ext3
  • 電源断
  • mount -t ext2
  • 色々書く
  • umount
  • mount -t ext3

ってやるとどうなるんでしょう。ちゃんとやってくれるのかな

_ [url] 「物理的な音楽の小売りは終わる」/ほか

及びリンク先の Study: CDs may soon be as final as vinyl.

何となくメモ。日本はどうなるのかね。

_ [comp] いや、その資料が間違っているんじゃないかと言う話なのですよ

なんだか日記に書く量ではなくなってきました……

その資料を読む限り、基本的に "Journal ファイル" が ext2 上にあるから、まともにジャーナルログが記録されない、と言う話だと思うのですが。

でも、コードを適当に読んでみた限りでは、どうもジャーナルログを書くために ext2 を経由していると思えないのです。JBD の初期化をしている fs/jbd/journal.c を簡単に追い掛けて行くと

  • ext3 は journal に外部デバイスが指定されていないなら superblock に 書かれている journal inode を journal_init_inode に渡す
  • JDB の jounal_init_inode は、渡された inode から (ファイルシステム(VFS?)側の関数を呼んで) 物理デバイスとブロックサイズを割り出し、journal log のサイズを調べる。 最終的に bmap を呼び、物理デバイス上の位置を特定する
  • その得られたブロックのリストに対して JBD による journal を開始する

と言う感じに読めました。 ……ただ、ext3 の bmap が何か特殊なことをやっているようなんですが、 そこら辺まではちゃんと見れていません。それに私にまともな知識がないので、 思い切り外している可能性は結構あります。どうなんでしょう?

本日のツッコミ(全1件) [ツッコミを入れる]

_ hidetosi [http://www.dd.iij4u.or.jp/~okuyamak/Documents/NetworkFileS..]


2003-10-04

_ [prog][ruby] VFS for ruby

コードを整理しつつごりごり。 とりあえずローカルファイルが扱えるようになったはず。……はず。

うーん。先が長い。 1.8 のみと言うことで避けていたけど、やっぱり open-uri 使うかな……

_ [deb][ruby] SystemStackError on arm & powerpc

本格的に動かないらしい……。

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

うー。間に合うかな。

_ [url] Apache based WebDAV Server with LDAP and SSL

本文書の目標は、認証に LDAP を利用する Apache + MySQL + PHP + WebDAV ベースのウェブアプリケーションサーバを構築することです。この文書は、LDAP トランザクションの暗号化に関する詳細な解説も行います。

[はじめにより引用]

_ [url] みそ煮込みの角丸

いつの間にかサイトが出来てる。

ともあれここは美味しいです。 名古屋に来たなら是非。


2003-10-08

_ [url] ノータッチ・デプロイメント - Web+Windowsという新たな可能性 -

JavaApplet みたいな物。.NET Framework ってこういう機能もあるのか……

_ [url] ShiftキーでCDのコピー防止措置を解除

家族そろってでびるまん(誤認 なんです 経由。

「平均的なユーザー」とは一体全体どんなユーザーだろう……。 自分の論拠に合うような母集団を定義すれば何でも言えるよね。 もしかしたら、その平均的なユーザーはコピーの方法なんて知らないから、 プロテクトなんぞつけなくてもコピーされないんじゃいないか?

_ [url][deb] LDAPv3 HOWTO on Debian

有り難い。

それはともかく smartdoc ですね。

_ [deb] この間の ruby のバグ

は close された模様。ひとまず良かった。 ……けど、ビルドに失敗したライブラリ群は方って置けば勝手にもう一度試してくれるのかな?

_ [prog][ruby] VFS for ruby

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.

アンテナとかで使えるかもしれない。

REXML が遅い

ディレクトリ一覧は WebDAV の拡張が使用可能ならそちらを使うようにする。 と言うわけで帰ってくるのは XML なのだけど。 REXML を使ってみたら激しく遅い……。ストリームモードでもかなり遅い。 仕方がないのでいい加減な正規表現でパースする事に。うーん……


2003-10-13

_ [misc] w3m から emacs 起動して長々と書いてから閉じたら

TEXTAREA だけ全部文字化けして暫く書く気が失せる。

やっぱり tdiary-mode を使うべきなのか。とりあえず deb 化待ち。

_ [url] Windows Longhornへの道 - 今分かっているすべて

面白そうではある。あとは使いやすければ良いけど……

_ [misc] 思想の展開

書いていたのが消えたので適当に。

どうせあらゆる物の9割は屑なのだ。投げられるコメントが屑ばかりなのも不思議ではない。 肯定的なひとや考えが変わった人は静かに頷くだけで表に出てこないと考えるのは愚かか。 黙った方が楽なことは確かだけど。

_ [misc] 生暖かい視線で見守っておりますのでそのまま突き進んで下さい

でもkazu氏も「あれでそんなこと言ってる様じゃ甘い」と言うようなことを仰っていましたが。


2003-10-18

_ [url] 五月雨に関する Wiki

良さそうだなと思っていたのだけど、リリース版はまだないのかぁ……

_ [url] 冷たい怒り

一部だけ抜き出しても分からない話なので引用はしないけど、ともあれ面白い。

ただ、その鬱屈した感情を「怒り」と呼ぶのはどうも抵抗がある。 ……かといって思い浮かばないのだけど。

_ [linux][url] ファイルシステム

及び「続・ファイルシステム」。

grub 周りとかとても参考になります。

資料的価値

Linux のファイルシステムは確かに今色々あって、どれも一長一短だと思うんですが。

Web 上のコメントは「このファイルシステムは全く使い物にならない」と言う様な 書き方が多すぎる気がする。何処に問題があるのかをある程度突きとめないと価値がない。

自分が酷いクラッシュに見舞われたからと言っても、そこで「*** はゴミだ」で 終わってしまったら他の人への資料にはならないわけで。 自分の経験なんてたかが知れてるし、「経験的に***はよく壊れます」というのも 統計的は意味がないし。どういう環境下でどういうことをしたら壊れたのかが分かれば 良いのだけど、なかなか難しいのが難点……。 結構色々壊しましたが、結局一つも資料になるレベルにない。嗚呼悔しい。

逆に、読む方も「何処が駄目なのか、どういう時に駄目なのか」と言うのをちゃんと 拾えるようにしないと。問題点を1つ指摘してるだけなのに「そうかだめなのか。ステ」 とか言って他に移行して、もっと厄介な問題にぶち当たるというのは悲しすぎる(正に私だ)。

ext3 のジャーナルはどうなってるんだ

本題。……と言っても情報ありませんが。

あるext3復旧レポート なんかを読むと、ますます強く感じることですが、 ext3は駄目です。遅いし、noflushdは効かなくなるし、ぶっ壊れることが非常に多いです。落ちてしまった時に、ジャーナリングに任せて復旧させると、かなりの確率で、余計に破壊されてしまうことがあるようです。じゃ、全然ジャーナリングの意味ないじゃん!自分はもう3、4回はやられました。 ext3使うぐらいなら、ext2使う方がよっぽどましです

[ファイルシステム - enbug diaryより引用]

経験的にも ext3 は落ちてから、ジャーナルログを使って復旧するときに壊れることしばし。 一度 data=journal モードに酷いバグがあって、ほぼ必ず壊されるときもありましたが、 それを除くとしてもたまに壊れた。何でなのやら。

とりあえず「ジャーナルログを記録するためにファイルシステムレイヤを経由するので、 遅延書き込みなどにより、ちゃんとログが記録されない」と言うわけでは ない 雰囲気なのだけどなぁ……。(この辺についてはとりあえず ext3とJBDにメモしておく。) もう少しちゃんと調べないとあってるのかどうかがかなり怪しいのですけど。

_ [misc] 八田氏フレーム

人に応じてインパクトのあるキーワードは異なるし、 誰もが言葉に自分に都合の良い意味を込めて文を書く。

黒衣さんの文章が残ってないことが悔やまれる。

_ [misc][comp] google.com がヘッダ無し 400 Bad Request を返す

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>(後略)

とか全くヘッダーの付いていない応答が帰ってくる。参ったな。

_ [url] Boehm GCを使おう

CやC++である程度大きなプログラムを書く場合,最大の問題点はメモリ管理である...(略)...ところが,このメモリ管理をプログラマが全然面倒見なくてすむ画期的な方法がある.それがBoehm GCだ.

[はじめにより引用]

_ [misc] ぐにゅ

議論は -misc で行われていたのか……


2003-10-19

_ [url] rdtool の --with-part オプション及び filter 機能

隠し/Undocumented 機能らしい。

これを使って多言語を同じファイルに突っ込んだり出来ないかと考えたけど、 難しそうだなぁ……

_ [url] NLUG問題 まとめサイト

yendot 経由。

_ [url] デジタル証券によるコンテンツ流通システム

今更だけどとりあえずメモ。 まだちゃんと読んでない……


2003-10-22

_ [misc] くは

結局2回とも行けなかった……申し訳ない……

ひたすら寝て少し復活……

_ [book] 富士見ミステリー文庫 - スーパー・ブースト計画

まいじゃー推進委員会! 経由。

イラストと【LOVE!】。 どう考えてもやばかったミステリー文庫が更にやばくなりそうな雰囲気……

そもそも最初に「ミステリー」とかつけた時点で負けているのじゃないだろうか。

_ [music] 1989-2003, Tra / Hedningarna

輸入盤だと随分安かったので2つ。北欧トラッドなのだけど、猛スピードで叩き付ける 様な歌い方がかなり独特。アップテンポな曲調にはかなりあって良い感じです。

amazonのレビューによればフィン語らしいです。どっちにしろ分からないんだけど。

_ [prog][ruby] VFS for ruby

stat も出来るようになったので。とりあえず beta1。

WebDAV サーバに置いてある zip アーカイブ中のファイルを直接 open("w") とかあほな事が出来ます。

しかし、最初に互換性の事を考えすぎて、そっちに引きずられてしまったのが問題だなぁ。 何とか巧くまとめる方向へ行かないと。

次に何をやろうか。sshfs 擬きとか妄想してみたが難しそうだ……


2003-10-23

_ [url] 東風フォントその後 (7) 〜

LC で話をしていただけるようです。

_ [misc] Re: LC2003 Lightning Talk

某S氏は申し込んで通ったそうですが、 一体何を話せば良いのかと今になって頭を抱えております。 5分なんですが。ええ。

そう言えば、最初に設定してあった締め切り日を過ぎたら、 締め切りの記述だけ消して今でも募集していますね。 よっぽど人居ないのでしょうか。

_ [url] 失われた "Re:原発がどんなものか知ってほしい - EiFYE原子力発電所"

これを出して良いのかわかりませんけど。

今でも辛うじて 妖精現実フェアリアルの 2002/9/3 付けの記事 (の一番下)にある zip アーカイブから読むことが出来ます。

もしも、 原発がどんなものか知ってほしい だけしか読んでいないならば、是非こちらも読んで下さい。 置かれていたサイトが消滅しているので、ここだけ抜き出してもニュアンスが 正確に伝わらないかもしれないのが残念ですが、ともあれ読んだ上で自分で考えましょう。 "Re: 原発がどんなものか知ってほしい" は faq10.html です。

ところで、「諸君、私は原発が好きだ」を保存しておかなかったのが悔やまれる……

_ [misc] トンデモ?

この言い方ってやはりと学会から 来ているのだろうか。

何か定義から随分ずれて使われて気になる……


2003-10-25

_ [url] REALITY CHECK:Power over Ethernetに注目すべき理由

Ethernet ケーブル経由で電源を供給する規格らしい。 既に製品出てる模様。

_ [url] アルマジロ - J

from /.j

こういうのを使いこなせる人はいいなぁ。

_ [comp] grub shell は便利だ

device なんてコマンドがあるとは知らなかった。

device (hd0) /dev/hda

等とするとそれ以降 /dev/hda が (hd0) として扱える。

これ、デバイスファイルだけではなく普通のファイルも渡すことが出来る。 フロッピーイメージがあったら、中に grub のファイル一式を置いておいて、

device (fd0) /home/sugi/works/boot.img
root (fd0)
setup (fd0)

とすればイメージに対して grub がインストールできる。 素晴らしい。


2003-10-28

_ [url] TomcatでWebDAVを実現

upstream じゃないけど、日本語の対応もしているのか。

_ [url] スミルノフ・グラブス検定

データが統計上有意かどうか判別する方法。

_ [url] sfs - Self-certifying File System

やすいしにおしえてもった。

セキュアなネットワークファイルシステム。 インターネット越しに使えて、しかも非常に簡単で使いやすい。

内部的には nfs を使っているのだけど、あの面倒くささとは大違いだ。 サーバが設定されているなら、クライアント側は sfsagent にキーを登録して /sfs/サーバFQDN に cd するだけでマウントできる。

_ [url] iHP-120

ogg も再生できる携帯プレイヤー。

RIO よりこっちの方がデザインは良いな…… 只の USB Strage に見えるみたいだし、使い勝手も良さそう。

_ [url][ruby] Ruby/DBI 翻訳文書

何時か使いそうなのでメモ。

_ [url] Ultra160 RAID de Go!

SCSI と RAID の面白そうなことが色々。 とりあえずメモ。

_ [url] 複製技術の時代におけるアート作品 - ベンヤミン

プロジェクト杉田玄白にあったのか……文庫かってしまった……

と言ってもまだ読み終えてないんだけど。


2003-10-29

_ [comp] ノートが戻ってきたので

今度はWindowsXPを残して置いて使ってみる。

リモートデスクトップが便利だ。VNC や X と違って、セッションを コンソールとリモートスクリーン間でに繋げたり切り離したり自由に出来る。

rdesktopでlinuxから使える。



Tatsuki Sugiura <sugi@nemui.org>