Re: Why doesn't disk io occur to read file system metadata despite clearing dentry and inode with drop_cache command?

[Jan Kara <jack@suse.cz>]

Hello,

On Wed 11-09-19 15:27:07, Daegyu Han wrote:
> I am confused about "echo # >/proc/sys/vm/drop_caches" and blockdev
> --flushbufs.  According to OSStep book written by Remzi,If the target
> inodes are not cached in memory, disk IO should be occur to readthe
> inode, which will make a dentry data structure on memory.  To my
> knowledge, echo 3 >/proc/sys/vm/drop_caches is to drop(clear) page
> cahche, inodes and dentry. I have experimented with blktrace to figure
> out whether disk io is really occurring to read the inode.
> 
> 1. echo 3 > /proc/sys/vm/drop_caches
> However, there is no disk io to read inode. I can only see the disk io
> to read 16KB data block.
> 2. echo 3 > /proc/sys/vm/drop_caches` and `blockdev --flushbufs
> /dev/nvme0n1I found block access (+8(512*8=4KB)) to read inode.
> 
> A quick look at how blockdev --flushbufs works in the kernel code shows
> that it clears the superblock.  Why doesn't disk io occur to read inodes
> with drop_cache alone?  The kernel book called ULK says that inodes and
> superblocks are cached in buffer-cache.Is this the reason for this?  I
> infer as follows:Is the buffer_head data structure not flushed to disk by
> drop_cache alone because the storage device is still mapped in memory?

Yes, I guess that's what happened. Note that drop_caches drop only clean
and unreferenced inodes, dentries & page cache. So if the inode is dirty
(e.g. due to atime update pending), drop caches won't free it. Another
effect may be that something (e.g. the jbd2 journal) holds onto the buffer
caching the inode table block with the inode.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR