ええと、get_sb_bdev() から呼ばれる open_bdev_excl() から呼ばれる blkdev_get() から呼ばれる __blkdev_get() あたりからログ。

帰宅後、着手したら lookup_bdev() が隣りの emacs で開かれている。関数定義直上に記述されているコメントが以下。 /** * lookup_bdev - lookup a struct block_device by name * * @path: special file representing the block device * * Get a reference…

昨晩の続き。 これって get_sb_bdev() 手続きに渡されてるナニ。 static int ext3_get_sb(struct file_system_type *fs_type, int flags, const char *dev_name, void *data, struct vfsmount *mnt) { return get_sb_bdev(fs_type, flags, dev_name, data, e…

VALUES_N と PUSH_HANDLERS とか。

fs ディレクトリにて以下のコマンドにて確認。 $ find|xargs grep s_desc_per_block_bits ./ext2/super.c: sbi->s_desc_per_block_bits = ./ext4/super.c: sbi->s_desc_per_block_bits = log2(EXT4_DESC_PER_BLOCK(sb)); ./ext3/super.c: sbi->s_desc_per_bl…

追いかける深さが増していくにつれ、中身の理解が必要になってきつつある。直前エントリで出てきた ext3_count_free_blocks() 手続き (fs/ext3/balloc.c) の中身を確認してみます。

super.c で free_blocks で探したら最初に見つかるのが ext3_check_descriptors() 手続きの中の以下の命令。 sbi->s_es->s_free_blocks_count=cpu_to_le32(ext3_count_free_blocks(sb));上記が何をしているのか、は別途。とりあえずこの手続きを呼び出してい…

grep してみた。fs/ext3 の中。 $ grep s_free_blocks_count fs/ext3/* fs/ext3/balloc.c: le32_to_cpu(es->s_free_blocks_count), fs/ext3/super.c: sbi->s_es->s_free_blocks_count=cpu_to_le32(ext3_count_free_blocks(sb)); fs/ext3/super.c: es->s_free…

掘っていく内にナチュラル判明。

もう少しメモ。

微妙に修正してこちらにも output。 ネタとしては df と du の数値の根拠とその根拠たる super block なブロック数がいつ更新されるのか、な調査。

とりあえず easy に BNUMNE をナニする事にしてメモを以下に控え。

さきほどまで仕事対応してたので出力は略。ってか入力ゼロ。 超ヤク日でした。今日は早めに (?) 寝ます。

DRBD が特集記事に。ブロックデバイスの処理に関するレイヤが図示されてたのをなんとなく目にしました。メモっとけば良かった。ある意味このあたりの理解が一つのポイントなので、3rd Edition の 14 章確認します。

投入する前に throw_continuatio() の概要説明を修正。残りは Scm_VMCallCC() なんですがどうしたものやら。

最初から再読してましたが、12 章以降に目を通す事に。相当集中して何度か読む必要があるな、と思ってるんですが具体的にどうしたものやら。

今日は県立図書館に昨日購入したナニとメモ用端末を持ち込み勉強。 # 結局メモは取ってないんですが ...

40 代だったりします。 でもどっちかというと_出力_で_表現_ではないな。

現実トウヒという訳ではないんですが、こちらもこつこつ進める方向で。

前から欲しかった 詳解 Linux カーネル 第3版 を購入。当分がっつり読む予定。できれば平行して unlink な実装を追い掛けてログを残したいな、な今日この頃。 別途、throw_cont_body の ReadingGauche なエントリを投入予定。

とりあえず throw_cont_calculate_handlers() は一旦スルー。

ええと、 (dynamic-wind (before0) ((lambda () (dynamic-wind (before1) (thunk1) ;; ここで cont に継続を格納 (after1)))) (after0))と (dynamic-wind (before2) ((lambda () (cont))) (after2))のナニで継続な cont を起動した瞬間の vm->handlers が以…

ええと昨晩の続き。 (dynamic-wind (before0) ((lambda () (dynamic-wind (before1) (thunk1) ;; ここで cont に継続を格納 (after1)))) (after0))な thunk1 で補足された継続を (dynamic-wind (before2) ((lambda () (cont))) (after2))みたいなカンジで継…

とか dynamic-wind とか。あるいは throw_cont_body() 手続きとか。

fs/ext3 配下にて s_blocks_count に属性に代入していると思われる箇所は resize.c のみな模様。 ext3_group_extend() ioctl.c の ext3_ioctl() から呼び出される super.c の ext3_remount() から呼び出される ext3_group_add() ioctl.c の ext3_ioctl() か…

何か色々な意味でとっちらかっててメモにさえなっとらん。スデに控えてるかもしれない部分含め以下に。

ざくっと理解、が一番微妙。

キヨシロー見る。

なんかカーネルがどうメモリを取り扱ってるか、な原則を全然理解できていない事が判明。これは致命的。

throw_cont_cc 手続きの概要下書き。