hiboma.hatenadiary.jp
前回の続きのエントリです
カーネルのバージョンを変えつつ ソースを読み込んでみたところ理解が進んだ点が２つあったのでまとめます
- ファイルシステム(マウントポイント?) を remount すると dentry を破棄できる
- evict_inodes() を呼んで inode のキャッシュ を破棄できる
この二点についてまとめます
1. ファイルシステムを remount すると dentry を破棄する
ファイルシステムを remount する際にカーネル内で reconfigure_super() (古いカーネルでは do_remount_sb() ) を呼び出すが、その中で shrink_dcache_sb() を呼び出して dcache を破棄する処理が入っているのを確認した
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() の定義は下記のような感じ
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 キャッシュを全て破棄(?)できるぽい
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);
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 が付いている
lore.kernel.org
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 の処理などは呼び出す側の責務っぽい。書き込みが発生している場合には慎重に扱わないとファイルシステムの不整合を招く感じする
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 を書いてみた
github.com
実験
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) を破棄する
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 等を起こさないかも試し中
まとめ
- とりあえずやりたいことは成功した
- カーネル内部の API 呼び出しは、呼び出す側がどういう条件を満たしれいれば安全なのかを把握するのが大変
- バージョンを変えてみるとカーネルの 内部 API に変更が入ってたりするので いろいろ見てみないといけない
