Proof of Concept: Linux カーネルモジュールで特定のディレクトリ以下の dentry キャッシュを破棄する (2)
前回の続きのエントリです
カーネルのバージョンを変えつつ ソースを読み込んでみたところ理解が進んだ点が２つあったのでまとめます
- ファイルシステム(マウントポイント?) を remount すると dentry を破棄できる
- evict_inodes() を呼んで inode のキャッシュ を破棄できる
この二点についてまとめます
1. ファイルシステムを remount すると dentry を破棄する
ファイルシステムを remount する際にカーネル内で reconfigure_super() (古いカーネルでは do_remount_sb() ) を呼び出すが、その中で shrink_dcache_sb() を呼び出して dcache を破棄する処理が入っているのを確認した
/** * reconfigure_super - asks filesystem to change superblock parameters * @fc: The superblock and configuration * * Alters the configuration parameters of a live superblock. */ int reconfigure_super(struct fs_context *fc) { struct super_block *sb = fc->root->d_sb; int retval; bool remount_ro = false; bool force = fc->sb_flags & SB_FORCE; ... shrink_dcache_sb(sb); 👈
shrink_dcache_sb() の定義は下記のような感じ
/** * shrink_dcache_sb - shrink dcache for a superblock * @sb: superblock * * Shrink the dcache for the specified super block. This is used to free * the dcache before unmounting a file system. */ void shrink_dcache_sb(struct super_block *sb) { do { LIST_HEAD(dispose); list_lru_walk(&sb->s_dentry_lru, dentry_lru_isolate_shrink, &dispose, 1024); shrink_dentry_list(&dispose); } while (list_lru_count(&sb->s_dentry_lru) > 0); } EXPORT_SYMBOL(shrink_dcache_sb);
remount する? それ、役に立つの?
「特定のファイルシステム/マウントポイントの dentry cache を飛ばしたい + mount ポイントが remount できる」 という特殊な条件が揃うようなケースがありえるのかどうか分からないが ... そういう時には使える。
あまり有用でない感じする. 無念
2. evict_inodes() を呼んで VFS inode キャッシュ を破棄する
evict_inodes() という関数で、対象としているファイルシステムの superblock にぶら下がる inode キャッシュを全て破棄(?)できるぽい
/** * evict_inodes - evict all evictable inodes for a superblock * @sb: superblock to operate on * * Make sure that no inodes with zero refcount are retained. This is * called by superblock shutdown after having SB_ACTIVE flag removed, * so any inode reaching zero refcount during or after that call will * be immediately evicted. */ void evict_inodes(struct super_block *sb) { struct inode *inode, *next; LIST_HEAD(dispose); again: spin_lock(&sb->s_inode_list_lock); list_for_each_entry_safe(inode, next, &sb->s_inodes, i_sb_list) { if (atomic_read(&inode->i_count)) continue; spin_lock(&inode->i_lock); if (inode->i_state & (I_NEW | I_FREEING | I_WILL_FREE)) { spin_unlock(&inode->i_lock); continue; } inode->i_state |= I_FREEING; inode_lru_list_del(inode); spin_unlock(&inode->i_lock); list_add(&inode->i_lru, &dispose); /* * We can have a ton of inodes to evict at unmount time given * enough memory, check to see if we need to go to sleep for a * bit so we don't livelock. */ if (need_resched()) { spin_unlock(&sb->s_inode_list_lock); cond_resched(); dispose_list(&dispose); goto again; } } spin_unlock(&sb->s_inode_list_lock); dispose_list(&dispose); } EXPORT_SYMBOL_GPL(evict_inodes);
4.13.3 から EXPORT_SYMBOL_GPL が付いている
4.13.3 からは EXPORT_SYMBOL_GPL が付いているので他のカーネルモジュールからも呼び出し可能な API として再定義されている.
evict_inodes() を呼び出す際の注意
コメントに注意書きが記してある
* Make sure that no inodes with zero refcount are retained. This is * called by superblock shutdown after having SB_ACTIVE flag removed, * so any inode reaching zero refcount during or after that call will * be immediately evicted. */
呼び出し側が上記の条件を保証する必要があるらしくて、ここの条件の成立のさせ方が正しいのかを確かめるすべがわからない.
evict_inodes() を呼び出すコードに generic_shutdown_super() があるが dirty な inode の処理などは呼び出す側の責務っぽい。書き込みが発生している場合には慎重に扱わないとファイルシステムの不整合を招く感じする
/** * generic_shutdown_super - common helper for ->kill_sb() * @sb: superblock to kill * * generic_shutdown_super() does all fs-independent work on superblock * shutdown. Typical ->kill_sb() should pick all fs-specific objects * that need destruction out of superblock, call generic_shutdown_super() * and release aforementioned objects. Note: dentries and inodes _are_ * taken care of and do not need specific handling. * * Upon calling this function, the filesystem may no longer alter or * rearrange the set of dentries belonging to this super_block, nor may it * change the attachments of dentries to inodes. */ void generic_shutdown_super(struct super_block *sb) { const struct super_operations *sop = sb->s_op; if (sb->s_root) { shrink_dcache_for_umount(sb); sync_filesystem(sb); sb->s_flags &= ~SB_ACTIVE; fsnotify_sb_delete(sb); cgroup_writeback_umount(); evict_inodes(sb); 👈 ...
ファイルシステムが readonly ならどうだろ???
今回調べているユースケースで、実は 対象のファイルシステムが実は「readonly でマウントしている」という隠れ条件 があったのでした (後出しジャンケンですいません)
おそらく、ファイルシステムが readonly でマウントされていたら dirty な inode は存在しえないだろうし、 slab キャッシュをばーんと消しても安全に扱えそうなきがする
... ということで readonly なファイルシステムを対象に evict_inodes() をカーネルモジュールから呼び出す Proofe of Conept を書いてみた
実験
XFS で looopback のファイルシステムを作成して、ディレクトリとファイルを作成しまくる
dd if=/dev/zero of=/tmp/disk bs=1M count=1000 mkfs.ext4 /tmp/disk sudo mount -t xfs /tmp/disk /mnt for i in $(seq 1 1000); do sudo mkdir -pv /mnt/$i/{1..100}; done for i in $(seq 1 1000); do sudo touch /mnt/$i/{1..100}/test.txt; done
readonly で remount しなおす
sudo mount -o remount -r -t xfs /mnt
dentry と xfs_inode を貯めるべく find する
sudo find /mnt >/dev/null
この時点で slabtop すると、以下の slab が溜まっている
OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME 201042 201042 100% 0.94K 11826 17 189216K xfs_inode 104192 101602 97% 0.50K 6512 16 52096K kmalloc-512 229383 224847 98% 0.19K 10923 21 43692K dentry ...
拙作のカーネルモジュールで dentry と inode (xfs_inode) を破棄する
# /mnt の superblock を対象にして dentry と xfs_inode を破棄する (はず echo /mnt | sudo tee /sys/kernel/debug/shrink_super_block_cache
slabtop しなおすと dentry と xfs_inode が消えた ( kmalloc-512 もなくなったな??? )
OBJS ACTIVE USE OBJ SIZE SLABS OBJ/SLAB CACHE SIZE NAME 16107 15673 97% 0.59K 1239 13 9912K inode_cache 8325 7409 88% 1.06K 555 15 8880K ext4_inode_cache 50430 50127 99% 0.13K 1681 30 6724K kernfs_node_cache 29883 24224 81% 0.19K 1423 21 5692K dentry ...
dentry cache と inode ( xfs_inode ) を破棄することに成功したぽい.
ext4 でも同様の結果を得ている. slab キャッシュの生成とキャッシュの破棄とを並列にするなどして kernel panic 等を起こさないかも試し中
