nDiki : ファイルシステム
Related term
2006年1月16日 (月)
■ USB HDD 上に ext3 ファイルシステムを作ろうとしたらフリーズ

会社で使っている Linux サーバ (DELL PowerEdge 2600)内のファイルについて、バックアップをとっていないのがずっと不安であった。
なので、まずは外付け HDD を接続して pdumpfs でバックアップしておくことにした。
以下の実作業は松下君が行ってくれたもの。
電源内蔵の HDD BUFFALO HD-H300U2 を購入。 比較的人気なのか、市場では品薄の様子。
購入時は FAT32 で1パーティションでフォーマットされている。 なんかいろいろソフトが入っているみたいだけれど、まあ使わないからいいや。 さっそく接続して mkfs.ext3 でファイルシステムの作成。
ここでトラブル。
inode table を書き込んでいる途中で進行状況を示す数字のカウントアップがだんだん遅くなっていき最後には止まってしまった。 おかしいなと思っているうちに Linux 自体がフリーズ。 SSHもWebも接続できないし、コンソールも反応なし。
一瞬「マズ。もしかして間違えて、システムの入っているパーティション指定しちゃった?」と思ったが、再起動すると問題なく立ち上がって一安心。
うーん。原因はなんだろう。いまだに Red Hat Linux 8.0 で Linux kernel も 2.4.20 のままなんだけれど、そのあたりに何かあるのだろうか。
- ファイルシステム作成はノート PC でやっておいた (2006-01-17)
- クラッシュは突然に - DAR の使用を再検討 (2009-01-06)
- 今日のさえずり - スポーツの制裁金ってどこにいくのだ? (2008-06-11)
- もしもの時に家族がデジカメデータ見られるように HDD 購入 (2009-08-27)
- バックアップ用に廉価ポータブルハードディスクを購入 (2009-08-21)
2006年1月17日 (火)
■ ファイルシステム作成はノート PC でやっておいた

昨日のHDD問題であるが、今日再度試してみたもののやはり途中で止まってしまう。
しょうがないので自分のノート PC 上で ext3 ファイルシステムを作成してからあらためて接続。 マウントは DELL PowerEdge 2600でも問題なくできた。 cron で毎夜実行している pdumpfs のバックアップ先を、USB HDD 側に変更しておく。 ちゃんと書き込めているか後で確認。
- USB HDD 上に ext3 ファイルシステムを作ろうとしたらフリーズ (2006-01-16)
- バックアップ用に廉価ポータブルハードディスクを購入 (2009-08-21)
- お買い物 (2004-01-02)
- もしもの時に家族がデジカメデータ見られるように HDD 購入 (2009-08-27)
- DAR で差分/増分バックアップ (2005-04-02)
2006年2月23日 (木)
■ Debian Linux kernel 2.6.15 ビルド

ThinkPad X31 用に 2.6.15 の Debian kernel パッケージ構築を行う。 インストールしてある Debian 標準の 2.6.15 のパッケージの設定 /boot/config-2.6.15-1-686 をベースに設定を行いビルド。
#apt-get build-dep linux-image-2.6.15-1-686 #exit $mkdir -p /usr/local/src/linux $cd /usr/local/src/linux $tar jxvf /usr/src/linux-source-2.6.15.tar.bz2 $cd linux-source-2.6.15 $cp /boot/config-2.6.15-1-686 .config $make menuconfig $make-kpkg clean $fakeroot make-kpkg --revision=sebastian.1.0 kernel_image $cd .. $su #dpkg -i linux-image-2.6.15_sebastian.1.0_i386.deb
ブート後 Kernel panic。
標準の設定では IDE 関係がモジュールになっているのを見落していた。もう一度設定を修正してビルドしなおして起動。 Linux を使い始めたころ ext2 をモジュールにして失敗したことがあり、ファイルシステム関連は忘れずチェックするようにしているのだが、IDE 関連はノーチェックだった。
@ MADWIFI
module-assistant prepare module-assistant auto-install madwifi
- Debian Linux kernel 2.6.26 にアップデート (2009-02-07)
- ThinkPad X31 と sid の Linux kernel 事情 (2009-10-04)
- Debian Linux kernel 2.6.23 をビルドする。 (2007-12-23)
- Debian GNU/Linux sid 環境を新 HDD へ (2006-07-29)
- Linux kernel 2.6.8 + MADWIFI (2004-09-20)
2006年6月10日 (土)
■ WiKicker における PageName 最長文字数

WiKicker では PageName を エンコードした文字列を URI に埋め込んだり、サーバで保存する際のファイル名にしたりしている。 このため、PageName の最長文字数はそれらの最長文字数に依存しているはずである。
今まで確認を後回しにしていたのだが、新しい機能の追加の際に確認しておく必要があるので調査してみた。
@ WiKicker の実装
WiKicker の実装がらみとして最長を決める要素としては
- PageName の UTF-8 表現を URI エスケープしてページ URI に含めている。→ URI、HTTP、HTML、Web サーバ、Web ブラウザの実装による最長の制約
- PageName を base64 にエンコードしてファイル名にしている。→ ファイルシステムのファイル名、パス名の最長の制約
がある。
@ 各仕様等による制約
- HTTP では URI の長さには制限なし (RFC2616 3.2.1)
- Web サーバは Request-URI が長いと 414 Request-URI Too Long を返す (RFC2616 10.4.15)。Apache は LimitRequestLine ディレクティブにより、URI を含むリクエスト行のサイズを制限することができる(配布時には 8190)。
- Internet Explorer が扱える URL の長さは 2083文字。
- ext2 はファイル名は 255文字まで(増やすこともできる)。
- 手元の Linux 2.6.15 で試したところ、パス名は 4095文字まで。
@ WiKicker で問題が出ない PageName 最長文字数
上記の中ではファイル名による制約が一番大きい。
WiKicker 内部でファイル名として base64 (の亜種) でエンコードしたものを使っているので、元の文字列はは最長 189バイトまでなければならない。base64 だと3バイトで4文字になるため、189バイトで 252文字となる。
WiKicker ではここでさらにファイル名に ',v'、'-lock' をつける事があるので、実際には元の文字列は最長 186 バイトまでとなる。
PageName が 186 バイトまでだとすると、URL エスケープしたとして558バイト。 WikiEngine のスクリプトの URL や他のパラメータとあわせても、これぐらいなら大丈夫のはずである。
ということで WiKicker では Linux 上だと通常 PageName は 186 バイトが最長と言ってよさそうだ。 日本語の文字はだいたい UTF-8 で3バイトになるので、62 文字までということになる。
そのうち、WiKicker に制約チェックを入れることにしよう。 そのうち。
- Windows 上での Apache 2.0.53 では PATH_INF... (2005-04-10)
- WiKicker 実装 (2002-10-20)
- WiKicker 0.35 リリース - 添付機能の修正など (2006-06-20)
- 最後がピリオド(.)で終わるファイル名をつけられない (2005-04-19)
- ケータイ用にプライベート Wiki を設置 (2008-01-07)
2006年8月8日 (火)
■ Linux で使えるデスクトップ検索ツール Beagle でローカルファイルを検索

Windows だと Google Desktop でローカルファイルの検索ができるのだが、残念ながら Linux 版はでていない。 そこで Beagle を入れてみることにした。
Beagle はデーモン形式のバックエンドと、検索インタフェースであるフロンエンドに分かれたているデスクトップ検索ツールである。
ファイルシステム上にあるテキストファイルだけでなくメールや、Firefox でアクセスしたページ、OpenOffice.org や Microsoft Office のファイルなどをインデックス化し検索できるようにすることができるらしい。
@ ちなみに今まで
ローカルファイルの検索は
| メール | Mew 4 での検索(with Namazu)。 |
| nDiki 記事 | howm で記事ソースデータを検索 (方法)、あるいは www.naney.org 公開記事を Google で。 |
| メモ | howm。 |
| 開発中のソースコード | Emacs の grep-find でだいたい事足りる。たまに ack。 |
| 仕事のメモ | できるだけ社内 Wiki か社内 Blog に書いておいて Hyper Estraier。 |
| その他 | grep 程度。 |
といった感じかな。
それ以外はだいたいファイルの位置をうろ覚えしているので、何カ所か探せば見つかることが多い。
問題はうろ覚えの場所になかった時。 その時はなかなか見つからない。
そんなファイルを見つけるのが楽になれば、導入効果あり。
@ インストールして試してみる
@ Linux kernel の inotify を有効にする
まずは Linux kernel の設定を確認。inotify が有効になっている方が良いらしい。 この間ビルドした時の .config を見て
CONFIG_INOTIFY=y CONFIG_EXT2_FS_XATTR=y CONFIG_EXT3_FS_XATTR=y
となっていることを確認。
@ /home の extended attributes を有効にする。
/etc/fstab を編集し、
/dev/hda4 /home ext3 defaults 0 2
を
/dev/hda4 /home ext3 defaults,user_xattr 0 2
に変更する。書き換えたら、
mount -o remount /home
でマウントしなおす。
@ Beagle のインストール
@ Beagle を起動
一般ユーザで
beagled
で起動する。停止は
beagle-shutdown
で。
@ Beagle を設定
beagle-settings
で設定 UI を起動し、インデックスに含めたくないディレクトリなどを設定。
@ 検索してみる
beagle-search
で検索 UI を起動し検索してみる。 日本語も OK のようである。
GNOME 環境をほとんどインストールしていなかったので、検索結果からファイルを開けずつまらなかたので gonome-control-center、gnome-panel あたりをインストールして環境設定等をしてみた。
@ Firefox 拡張
xpi ファイルを入れておく。 後は普通に閲覧したページが、Beagle でインデックス化されて検索できるようになる。
設定してしまえば、以前開発して使っていた WWWOFFLE + Namazu よりお手軽である。
@ 感想
デーモンが逐次インデックス化していくので、明示的定期的にインデクサを走らせなくていいというのは楽でいい。
日本語関連がどの程度うまく検索できるのか、検索結果は使いやすい順に出力されるのかが未知数。 しばらく遊んでみて便利かどうか確かめてみたい。
- Evernote 使用開始 (2009-03-03)
- Google Desktop Linux 版をインストール (2007-07-02)
- Linux 母艦ノート PC を使わずに仕事ができるかチャレンジ (2007-08-20)
- メールボックスを Gmail に集約 (2007-08-08)
- Debian GNU/Linux に Hyper Estraier 1.2... (2006-05-31)
2007年2月2日 (金)
■ DiKicker に grep 検索機能を追加

DiKicker には自動リンクベースの記事串刺し表示機能があって、同じキーワードを含む記事をまとめて読むことができる。 結構便利なのだが、この機能ではキーワードの設定は Blog の書き手に委ねられている。
社内で DiKicker を一部使ってもらっているのだけれども、それら他人の Blog を読んでいると「あのキーワードで串刺し表示したいな」と思うことがしばしばあることに気がついた。 やはり任意の文字列で串刺し表示する機能が欲しい。
書き手にとっても「自動リンクキーワードにするような文字列ではないけれども、串刺しで読みたい/探したい/見せたい」と思うことが少なからずある。
@ grep ベース
実現には全文検索を行う必要があるが「設置・運用の手間」「ディスク容量」という点から、事前にインデックスを生成するような方法は今回は避けようと思う (www.naney.org 上で自分が使う上での制約からくる理由が一番大きかったりする)。
ということで今回は grep 型で実装することにした。 もともと WiKicker の方の検索機能も現在のところ grep 型である。 WiKicker では自前で WikiPage をスキャンしているが、DiKicker では grep コマンドに任せることにした。 こういうのは専用の grep を使った方が速いはず。呼び出しは
grep -Flre $escaped_string dir...
というオプション指定。Web ページとしてのページングなどは、自動リンクによる串刺し表示機能のものを流用。
で試したところ www.naney.org サーバでは、load averages が 1 以下の時でだいたい50秒前後。対象ファイル数は 2800弱。予想より時間がかかる。
ただし1回実行した後、ファイルがファイルシステム/OSのメモリ上にのっている状態では 0.1秒程度で完了する。
検索結果ページの permalink が検索エンジンにそれなりに捕捉されて、定期的にアクセスがあるようになれば、ファイルがメモリにのっている割合が増えるであろうから平均して実用に耐えられる速度が出るかもしれない。
今後は様子をみながら検索結果のキャッシュ等を処理を整備していく予定。
- WiKicker 0.420 リリース - 変更いろいろ (2007-05-30)
- 私的10大ニュース2004 [ web ] (2004-12-31)
- [ WiKicker ] 「最近のアクセスログ」処理思案 (2004-01-17)
- [ WiKicker ] Memcached を使った検索結果のキャッシング (2004-01-15)
- Debian GNU/Linux に Hyper Estraier 1.2... (2006-05-31)
2007年12月23日 (日)
■ aufs を使って Web サイトのドラフト作成する

この nDiki はローカル PC 上で Emacs で記事ファイルを書き、出来上がったら Unison で Web サーバと同期させる形でアップロード・公開している。
この方法で一つ問題なのは「書きかけの記事ファイル」の扱いが面倒なこと。 書きかけの記事ファイルがある状態で Web サーバと同期するとそれが公開されてしまうのでまずい。しかし完成している記事ファイルがあるならばそちらは同期して順次公開したい。 同期する時には書きかけの記事ファイルを退避させればいいのだが、思いっきり面倒。
ということで手元で公開用 (Web サーバ と同期用)のディレクトリツリーと、ドラフト用(ローカルの Web サーバでのレビュー用)のディレクトリツリーを分けられるようにすることにした。 この2つのディレクトリツリーの差分となる草稿・更新ファイルは aufs を使うことで簡単に管理することができる。
@ aufs
aufs は stackable unification filesystem の一つ。 同様なものとしては UnionFS がある。 UnionFS よりも aufs の方が評判が良いようなので今回は aufs を使うことにした。
aufs では複数のディレクトリ(ブランチと呼ぶ)をオーバーレイさせて、1つのディレクトリとして扱うことができる。 公開用ディレクトリツリーに、ドラフト用ディレクトリツリーをオーバーレイさせることで、元のディレクトリには変更を加えることなく透過的に変更できる仮想的なディレクトリツリーを作ることができる。
@ aufs のインストール
Debian GNU/Linux sid へはkernel 再構築とあわせて module-assistant でインストールした。
@ マウント
以下のように3つのディレクトリを作ってマウントする。
- /home/naney/www.naney.org
- 公開用ディレクトリツリー。本番モノ。公開サーバと同期する。
- /home/naney/draft.naney.org
- 草稿や修正されたファイルが書き込まれるディレクトリツリー。
- /home/naney/next.naney.org
- 公開用ディレクトリツリーに、草稿や修正されたファイルが仮想的にオーバーレイされたディレクトリツリー。プレビュー用。
mount -v -t aufs -o br:/home/naney/draft.naney.org=rw:/home/naney/www.naney.org=ro none /home/naney/next.naney.org
公開ディレクトリツリーは read only に、草稿用のディレクトリツリーは read - write になるように指定する。
これで /home/naney/www.naney.org 以下はいじらないまま、/home/naney/next.naney.org 上で草稿を書いたりファイルを編集したりすることができる。 /home/naney/next.naney.org 以下で追加したファイルや、変更したファイルは aufs が /home/naney/draft.naney.org 上に保存してくれる。
完成したものを /home/naney/draft.naney.org から /home/naney/www.naney.org に順次反映させ(移動し)、公開サーバへ同期することで公開していくことができる。
手元ではいろいろ書き散らせておけるのは、これは便利。
マウントオプションは他にいろいろあるようなので、こまかい設定は見直すかも。
@ その他
ファイルシステムレベルの処理なので、アプリケーション側では何も手を加えなくてもよいのが良い。
今回は公開用とドラフト用としたが、公開用と未公開用をローカルでミックスして表示するようにしたり、複数ユーザのコンテンツディレクトリを仮想的に1つにまとめたりと、いろいろ面白い使い方ができそうだ。
- はいぱー日記システムで日記を開始 (2001-05-11)
- aufs で inotify を使ってブランチ上の直接の変更をすぐに反映させる (2008-01-05)
- www.naney.org をさくらのレンタルサーバへ移転 (2009-12-23)
- Debian に RSS リーダ「フレッシュリーダー」をインストール (2006-03-06)
- はいぱー日記システムアップデート (2001-05-19)
2008年2月21日 (木)
■ flickrfs で Flickr をマウントして写真をコピーする

Flickr 上の画像を読み書きするのに、Linux 的にはやっぱりファイルシステムとしてマウントして処理したいと考える。 もちろん世の中そういうのを作っている人がいるわけで、それが flickrfs。 セットアップしてみた。
@ セットアップ
@ インストール
flickrfs Debian パッケージを Debian GNU/Linux sid BOX へインストール。
@ FUSE の設定
Linux 上の自分のアカウントで FUSE を使えるようにする。
adduser ユーザ名 fuse
@ flickrfs の設定
~/.flickrfs 上に設定ファイルを用意する。
mkdir ~/.flickrfs emacs ~/.flickrfs/config.txt
config.txt:
[configuration] browser:/usr/bin/iceweasel set.sync.int:300 stream.sync.int:300 add.default.tag:no APIKey:xx Secret:xx
@ ~/flickr にマウントする
cd mkdir flickr flickrfs flickr
@ 見てみる
自分のセットの一覧が出る ls ~/flickr/sets セットの中の画像ファイルリストを見る ls ~/flickr/sets/<セット名> 自分のタグ別ディレクトリアクセス用ディレクトリ 自動的には何も取得されない ls ~/flickr/tags/personal Chicago タグのファイルリストを見る mkdir ~/flickr/tags/personal/Chicago ls ~/flickr/tags/personal/Chicago パブリックのタグは ~/flickr/tags/public/<タグ名> で
メタデータは「.<タイトル>.jpg.meta」ファイルで読み書きできるらしいが、試していない。
@ アンマウント
fusermount -u flickr
@ メモ
指定したタグ中の同じタイトルの写真はどれか1つかアクセスできないみたい。
- Dropbox for Linux を Debian 用にビルドしてインストール (2009-11-24)
- sid の CinePaint がプラグイン読み込みでエラー (2006-04-15)
- 今日のさえずり - 5:30 起床でもまだ時間が足りない (2009-09-12)
- 今日のさえずり - ピカチュウと写真撮ってもらえる列に並んでる (2009-11-24)
- ThinkPad X31 と sid の Linux kernel 事情 (2009-10-04)
2008年9月11日 (木)
■ 研究室 OB Twitter-ers と秋葉原で飲んだ

研究室仲間の田中丸君が今日は両国まで来ていると Twitter で知ったので、同じ研究室仲間で秋葉原で働いているやまだ君にも声をかけて、秋葉原で飲むことにした。 3月15日以来、約半年ぶりだ。
そういえば Twitter で声をかけてというのはリアル友人とはいえ自分にとっては初めてだな。
場所は矢まと秋葉原店。 前回の記事にはドリンクがくるのが遅かったと書いてあるけれど、今回はそんなことをなかった。
隣のテーブルでは、男が嫌がり気味の女をバシバシ写真で撮っていたようだけれど何だろアレ。
@ 話題
- やまだ君が買った iPhone に指紋をつける。初めて iPhone に触れてみた。ソフトウェアキーボードは慣れがいるなというのが印象。華やかさはアップルらしい。
- 久しぶりに SO905iCS でスマイルシャッター使ってみた。田中丸君は撮れたけれど、やまだ君は NG。髭のせいか照明のせいか。
- 伊勢海老密漁。
- Flickr 見ているといい写真多くて凄いねぇ。
- Flickr ファイルシステムにマウントする話(コレ)とか、SSH でマウントする話とか (shfs あたり)。
- 「デジタル一眼レフに移行しないの?」「PC 関係の投資の必要性がねぇ」「別にカメラメーカーのソフトウェア使う必要ないから Linux でもいいんじゃない? カメラメーカーのソフトウェアはインタフェースがこなれてないしね」
- 最初に買ったデジカメ? コダックの DC50 ね。
- eneloop 便利だね。
- NeXT とうとう捨てたよ。
- アップルは囲い込まれちゃえば便利だしいいよね。
- SCSI ケーブルが高く売れるとか、ワイヤレス USB どうよとか。
Mac OS X 使いのやまだ君と、Debian GNU/Linux 使いの自分と、基本 Windows だけれどオールラウンドな田中丸君とまあそれぞれ嗜好は違うのだけれど、御互い尊重しあってていい関係といった感じだ。
Linux デスクトップユーザとしてのメリットは「(自分の場合)アクセサリーとか周辺機器とか動かない可能性があってあまり買おうと思わないので、お金を使わなくて良いこと」と吹いておいた。
やまだ君の「Ctrl-p で印刷とかイライラする」というのには激しく同感。
妻が帰省中だということを理由に料理多めにもらって、あまり飲まないというのを理由に割り勘率下げてもらった。Thanks!
- 今日のさえずり - 待受画面が巨大仏像写真なのでビビった (2009-11-06)
- トイデジカメ VQ1005 来た (2008-03-08)
- 今日のさえずり - 上げ潮特大号 (2008-09-18)
- Debian GNU/Linux で Dropbox (2008-09-16)
- ヨドバシカメラのデジカメプリントの品質に満足 (2008-03-28)
2009年7月28日 (火)
■ FriendFeed から twitterfeed へ

10日ほど前に Twitter へのフィード投稿を twitterfeed 経由から FriendFeed 経由に変更してみた(記事)のだけれど、挙動がニーズにマッチしないので twitterfeed に戻した。
FriendFeed の Twitter 投稿機能だと date がちょっと古いフィードアイテムは新着でも投稿されないっぽいのである。
nDiki で使っている DiKicker の RSS フィードでは、アイテムの date を最初の公開日時ではなくファイルシステム上にある記事ファイルの更新日時としている。 このためローカルホスト上で記事ファイルを作成し、例えば半日後に Unison で Web サーバへファイル同期させて公開するとその時点で半日前の日時の記事が新着となる。 twitterfeed ではこのような場合でも新着として Twitter へ投稿してくれるのだが、FriendFeed ではどうも新着であってももう旬ではない記事として投稿してくれないっぽい。 挙動の設定も変更できなさそう。
ということで FriendFeed の Twitter 投稿を止めて、twitterfeed の設定を再アクティブ化。twitterfeed も OAuth に対応したり利用できる URL 短縮サービスが選べるようになっていたりと着実に改良されているので今後も継続してサービスされていくことを期待したい。
[ Twitter 関連サービス ]
- これで確定? Twitter へのフィード投稿を FeedBurner へ。 (2009-12-16)
- twitterfeed から FriendFeed へ (2009-07-17)
- FeedTweet は今後に期待 (2009-12-11)
- 今日のさえずり - Twitterご利用明細書きた。1年分請求額 12,3... (2009-12-14)
- Twilog で tweet をセカンダリロギング (2010-02-09)
■注目キーワード
購入 買った 発売日 フリー 無料 価格 値段 作り方 選び方 使い方 方法 設定 サンプル ダウンロード 限定 在庫 予約 穴場 比較 検証 レビュー 感想 評価 評判 使用感 使ってみた 口コミ 噂 最新 MP3 動画 意味 お薦め お勧め おすすめ 便利 Blog ブログ mixi 修理 デザイン ビックカメラProcess Time: 0.032815s / load averages: 0.39, 0.16, 0.10
nDiki by WATANABE Yoshimasa (profile)
Powered by DiKicker
Base theme by Nana (for tDiary)





◇ Twitter やってます。この記事が気にいったらぜひ twitter.com/Naney の follower になってください。