Hatena::Groupfilesystem

fs_n314

2009-05-27

iget()がなくなっていた

| 22:24 |  iget()がなくなっていた - fs_n314 を含むブックマーク はてなブックマーク -  iget()がなくなっていた - fs_n314

メモ

深追いできそうなら後で書く。

http://kerneltrap.org/mailarchive/linux-kernel/2007/10/12/335805


しかし何たる反応の遅さ。

トラックバック - http://filesystem.g.hatena.ne.jp/n314/20090527

2008-05-23

lookup_one_lenからlookup

| 18:11 |  lookup_one_lenからlookup - fs_n314 を含むブックマーク はてなブックマーク -  lookup_one_lenからlookup - fs_n314

以前の疑問が後ろ向きに解決した。

VFSの中で、__lookup_hash()にnameidataをNULLで渡している。これもよくわからない。そんなことして大丈夫なの?

lookup_one_len関数 - fs_n314 - filesystemグループ

大丈夫じゃなかった。

というか、自分のファイルシステムの実装が駄目だった。


どうもi_op->lookupはnameidataがNULLのときでもちゃんと動くようにしなければならないらしい。

というか、ext3などのファイルシステムではnameidata自体が使われていない。


というわけで、可能な限りlookupの中でnameidataは使うなということで解釈。

トラックバック - http://filesystem.g.hatena.ne.jp/n314/20080523

2008-04-27

属性操作が呼ばれる場合のメモ

| 18:29 |  属性操作が呼ばれる場合のメモ - fs_n314 を含むブックマーク はてなブックマーク -  属性操作が呼ばれる場合のメモ - fs_n314


  • vfs_readdir()
    • file_accessed()
      • touch_atime()
  • __do_follow_link()
    • touch_atime()
  • sys_readlink()
    • sys_readlinkat()
      • touch_atime()

ファイルのread()では fsnotify_access() が呼ばれているが、この中で具体的に何が行われているのかは後で調べる。

トラックバック - http://filesystem.g.hatena.ne.jp/n314/20080427

2008-04-24

bonnie++を使う場合の注意

| 23:55 |  bonnie++を使う場合の注意 - fs_n314 を含むブックマーク はてなブックマーク -  bonnie++を使う場合の注意 - fs_n314

1.03aのソースを見る限り、デフォルトではfsyncは発行されない、ただし、1.93c では既にデフォルトで最後にfsyncが発行されており、修正されている。但し、1.03aではfsyncを発行させるオプション'-b'をすれば良いらしい。(というか指定しなければ正しい結果は得られない、、、と思う。)

no title

忘れがちなのでメモ

debianでの環境を書いていてくれて助かる。


ただ、ファイルシステムデバッグ情報を表示すると、O_SYNCフラグが指定されていたんだけどどうなんだろう。

2.4 より前のカーネルでは巨大なファイルに fsync() を使用することは効率が悪い場合がある。別の方法として open(2) の際に O_SYNC フラグ使用するのが良いかもしれない。

404 - エラー: 404

同じ意味で、むしろO_SYNCを推奨しているような書き方だ。



あと測定時間が短くて+が表示される場合の対応。

修正前

#define MaxDataPerFile (MaxNameLen + 6 + 1 + 4)
#define MinTime (0.5)
#define Seeks (8192)

修正後

#define MaxDataPerFile (MaxNameLen + 6 + 1 + 4)
#define MinTime (0.01)
#define Seeks (8192)
no title

debianソースパッケージを変更する場合は、bonnie.h.inを修正。



結果の見方の和訳。

http://d.hatena.ne.jp/yoshifumi1975/20080320/p2

トラックバック - http://filesystem.g.hatena.ne.jp/n314/20080424

2008-04-16

mntput()にハマった

| 01:35 |  mntput()にハマった - fs_n314 を含むブックマーク はてなブックマーク -  mntput()にハマった - fs_n314

fput()はmntput()を呼び出すのね。

ファイルアクセスのたびにvfsmountデータが書き換わっているとは。


カーネルで他のファイルシステムを操作していて、確保していたファイルシステムデータがいつの間にか無効なアドレスになっていてハマった。

ファイルを開いて閉じた時に、mntput()が呼び出されてファイルシステムデータが開放されていた模様。

NULLじゃなくて適当アドレスが入っているから、原因を特定するのにかなり時間がかかった。


それではどこでmntget()が呼び出されているかというと・・・mntget()はインライン関数ブレークポイントが設定できないから分からなかった。。

トラックバック - http://filesystem.g.hatena.ne.jp/n314/20080416
日記の検索