☰

Linuxカーネル書き込みストレージメカニズムのinode番号が0の理由は何ですか？

tag-icon • tag-icon linux-kernel ext4 inode
Linuxカーネル書き込みストレージメカニズムのinode番号が0の理由は何ですか？

私はLinuxカーネルを使っています。現時点ではv3.10.61でのみ機能し、これは概念の証明にすぎません。

特定のWRITE \ READ操作のデータ型に関するいくつかのヒントをハードウェアに渡す必要があります。たとえば、inodeビットマップ読み取り、ログブロック書き込み、ユーザーデータ書き込みなど...

私はドライバーレベルbio structでrequest_queue struct。

  1. 次のコマンドでFSを作成しました。 mkfs.ext4 -b 4096 -E lazy_itable_init=0,lazy_journal_init=0 -m 0 /dev/vda
  2. 次のコマンドを使用してインストールしました。mount -o rw,nosuid,nodev,discard,noauto_da_alloc,data=ordered /dev/vda /mnt
  3. ブレークポイントの追加virtio_blk.c:377とログ関連の書き込みのスキップ
  4. このddコマンドを実行してください。 dd if=/dev/urandom of=/mnt/foo2 bs=764 count=34
  5. ブレークポイントがヒットするのを待ち、書き込み保存サブシステムでトレースを分析します。

追跡内容は次のとおりです。

#0  virtblk_request (q=0x87ab8000) at drivers/block/virtio_blk.c:377
#1  0x801c0b4c in __blk_run_queue_uncond (q=<optimized out>) at block/blk-core.c:312
#2  __blk_run_queue (q=0x87ab8000) at block/blk-core.c:329
#3  0x801c0c94 in queue_unplugged (q=0x87ab8000, depth=<optimized out>, from_schedule=<optimized out>) at block/blk-core.c:2920
#4  0x801c3a98 in blk_flush_plug_list (plug=<optimized out>, from_schedule=false) at block/blk-core.c:3030
#5  0x801c3d9c in blk_finish_plug (plug=0x8785fd8c) at block/blk-core.c:3037
#6  0x80091644 in generic_writepages (mapping=<optimized out>, wbc=0x8785fde0) at mm/page-writeback.c:1910
#7  0x80092a88 in do_writepages (mapping=<optimized out>, wbc=<optimized out>) at mm/page-writeback.c:1923
#8  0x800e7084 in __writeback_single_inode (inode=0x8740c290, wbc=0x8785fde0) at fs/fs-writeback.c:454
#9  0x800e7360 in writeback_sb_inodes (sb=0x87811000, wb=0x87ab81b0, work=0x8785fea4) at fs/fs-writeback.c:678
#10 0x800e757c in __writeback_inodes_wb (wb=0x1 <__vectors_start>, work=0x3ff) at fs/fs-writeback.c:723
#11 0x800e7760 in wb_writeback (wb=0x87ab81b0, work=0x8785fea4) at fs/fs-writeback.c:854
#12 0x800e838c in wb_check_old_data_flush (wb=<optimized out>) at fs/fs-writeback.c:969
#13 wb_do_writeback (wb=0x87ab81b0, force_wait=0) at fs/fs-writeback.c:1010
#14 0x800e848c in bdi_writeback_workfn (work=0x87ab81bc) at fs/fs-writeback.c:1040
#15 0x80039d34 in process_one_work (worker=0x87816180, work=0x87ab81bc) at kernel/workqueue.c:2189
#16 0x8003a40c in worker_thread (__worker=0x1 <__vectors_start>) at kernel/workqueue.c:2313
#17 0x8003f714 in kthread (_create=0x87845e20) at kernel/kthread.c:200
#18 0x8000dfb8 in ret_from_fork () at arch/arm/kernel/entry-common.S:91

さて、行く...フレーム8ではまだ確認するinode変数を最適化していません。

p (*inode)->i_ino
$7 = 0

このinodeが何を意味するのか、誰が説明できますか？そのようなinodeに関する情報はどこにありますか？書き込み保存ジョブのinode番号を追跡する方法は？

ベストアンサー1

免責事項：私はまだこれらの機能を使用したことがなく、文書やコメントを書いています。私の観察が間違っている可能性があります！

i_inoその値を使用すると見なすことができる唯一の関数は、インデックスノードがハッシュされている場合（まだ表示されていない場合）、ダーティとしてマークされ、タイムスタンプ（将来の書き込み保存操作用）を設定するfs/writeback.c内部関数です。block_dump___mark_inode_dirty書き換えられる現在のinodeのリストは、struct bdi_writeback *wb与えられたlist（）で利用可能に見えますwb_writeback()。

マウントオプションを使用すると、data=orderedデータの書き込み保存が発生しないと思われるため、inodeを「汚れた」と見なすべきではありません。 ~によるとext4 ドキュメント:

data=ordered(*)

すべてのデータは、メタデータがジャーナルにコミットされる前にデフォルトのファイルシステムに直接適用されます。

ext4での書き込み保存の動作方法については後述する。

データスキーマ

  • 書き込み保存モード

mode data=writeback、ext4はデータをまったく記録しません。このモードは、XFS、JFS、およびReiserFSのデフォルトモードであるメタデータロギングと同様のロギングレベルを提供します。競合+回復により、競合の直前に作成されたファイルのデータが正しくない可能性があります。このモードは通常最高のext4パフォーマンスを提供します。

  • 注文モード

モードでは、data=orderedext4はメタデータのみを正式に記録しますが、データブロックを介してデータ変更に関連するメタデータ情報をトランザクションという単一の単位に論理的にグループ化します。新しいメタデータをディスクに書き込む必要がある場合は、関連するデータブロックが最初に書き込まれます。通常、このモードは書き込み保存より少し遅くなりますが、ログモードよりはるかに高速です。

ext4パーティションでイベントを追跡するには、ext4-JBD2インターフェイスの仕組みfs/ext4/ext4_jbd2.cとinclude/trace/events/ext4.h。

おすすめ記事